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their  software  products,  efficiency  in  producing  them,  and 
their  ability  to  accurately  predict  the  cost  and  schedule  of 
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Both  Sides  of  the  Fence 


After  graduating  from  college,  I  took  a  job  with  a  major  defense  contractor  work¬ 
ing  on  a  variety  of  defense  software  projects  that  ranged  from  aircraft  modeling 
and  simulation  to  laser  communications  research  and  analysis.  After  eight  enjoyable 
years,  my  husband  was  faced  with  a  job  change  that  meant  moving  to  another  part  of 
the  country.  I  found  myself  searching  for  a  new  employer. 

The  biggest  employer  in  our  new  location  was  the  Department  of  the  Air  Force, 
and  sure  enough  they  were  hiring  engineers.  With  my  resume  in  the  Air  Force's  per¬ 
sonnel  system  I  was  asking  myself,  "How  can  I  give  up  the  green  grass  of  the  contractor  side 
of  the  fence  and  work  for  the  U.S.  government?"  The  Air  Force  made  me  an  offer  worth  con¬ 
sidering:  They  matched  my  salary,  paid  for  my  move,  and  placed  me  in  a  high-maturity  software 
development  organization.  Not  such  a  bad  deal  and  definitely  worth  a  try. 

I  am  happy  to  say  that  I  recently  celebrated  my  10-year  anniversary  of  working  as  a  civilian 
engineer  for  the  Department  of  the  Air  Force.  Yes,  it’s  a  different  side  of  the  fence  that  has 
many  stereotypes,  but  the  change  has  offered  me  fun  and  challenging  work.  And  currently,  it  is 
very  rewarding  tobeinmyCrossTal  k  position  that  is  committed  to  helping  the  D  epartment 
of  D  efense  and  industry  understand  and  overcome  software  engineering  challenges  on  both 
sides  of  the  fence. 

Today’s  scientific  and  engineering  professionals  make  job  changes  much  more  frequently 
than  was  typical  10  to  20  years  ago.  Why?  Many  make  the  change  to  obtain  a  higher  salary,  gain 
a  higher- ranking  position,  or  fulfill  a  need  to  try  something  different.  D  ue  to  this  trend  of  career 
hopping,  it  is  extremely  challenging  for  any  employer  to  keep  its  workforce  happy.  I  believe  this 
is  even  more  of  a  challenge  for  the  U.S.  Air  Force  and  government  at  large. 

Because  of  the  current  and  future  expected  shortage  of  engineers  and  scientists  in  the  Air 
Force,  G  en.  Lester  L.  Lyles,  commander  of  the  Air  Force  Materiel  Command  (AFMC),  declared 
2002  as  the  Year  of  the  Engineer  and  Scientist,  or  YES.  Because  of  the  importance  of  this  ini¬ 
tiative,  we  chose  YES  as  the  theme  of  this  month's  issue  and  begin  with  Command  L  aiders  Say 
YES  to  E  ngineers,  Saentists  by  Tech.  Sgt.  Carl  N  orman.  In  this  article,  Lyles  and  James  A .  Papa, 
AFMC  Engineering  and  Technical  Management  director,  comment  on  the  YES  initiative  and 
how  it's  helping  to  focus  the  Air  Force's  attention  on  workforce  training  and  development, 
workforce  size  and  mix,  and  motivation. 

This  article  is  followed  by  Leif  E.  Peterson,  AFMC's  chief  of  Civilian  Personnel  and 
Programs  Division,  discussing  the  criticality  of  the  scientific  and  engineering  workforce  along 
with  staffing  level  predictions  and  initiatives  such  as  phased  retirement. 

Besides  the  Air  Force,  the  Army  is  also  recognizing  the  importance  of  its  engineers  and  sci¬ 
entists.  In  A  my  Transformation:  Unifomed  A  rmy  Saentists  and  E  ngineers,  Lt.  Col.  Barry  L.  Shoop 
and  Lt.  Col.  Kenneth  L.  Alford  discuss  a  new  officer  career  path.  By  creating  a  new  functional 
area,  the  Army  will  support  a  core  population  of  scientists  and  engineers  who  has  been  educat¬ 
ed  in  applied  physical  sciences  and  who  has  advanced  degrees  in  disciplines  such  as  aeronauti¬ 
cal  engineering,  computer  science,  electrical  engineering,  physics,  and  many  more.  Although  we 
did  not  receive  the  Navy's  or  the  Marine  Corps’  perspective  on  our  theme  topic,  we  are  inter¬ 
ested  in  learning  of  any  similar  initiatives  in  these  services. 

In  addition  to  our  YES  section  of  articles,  we  have  a  great  set  of  supporting  articles  this 
month.  I  offer  a  special  thanks  to  these  contributing  authors:  Jeffrey  L.  Dutton,  Maj.  Brian  G. 
Hermann,  Dr.  Richard  C.  Shirkey,  Melanie  G ouveia,  Grady  Booch,  and  David  B.  Putman.  Also, 
since  we  are  wrapping  up  another  calendar  year  atCrossTal  k,  we  provide  you  with  our  2002 
Article  Index.  If  there  is  an  article  that  peaks  your  interest,  don’t  forget  to  look  it  up  on  our  Web 
site  <www.stsc.hill.af.mil>. 

You  can  form  your  own  opinion  about  government  vs.  commercial  employment.  As  for  me, 
I  really  do  enjoy  working  as  a  civilian  engineer  for  the  Department  of  the  Air  Force.  I  am  also 
pleased  with  the  current  recognition  of  the  Air  Force’s  engineering  and  scientific  workforce 
along  with  their  increasing  importance  to  our  nation's  security.  If  you  do  find  yourself  consid¬ 
ering  a  job  change,  don't  hesitate  to  look  into  a  position  in  the  Air  Force  or  other  services.  You 
might  find  that  the  grass  is  just  as  green  on  the  other  side  of  the  fence. 

A,  , 

Tracy  L.  Stauder 
Publisher 
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Year  of  the  Engineer  and  Scientist 


Command  Leaders  SayYES  to  Encpneers*  Scientists 

Tech.  Sgt.  Carl  Norman 
A  ir  Force  Materiel  Command 

Today,  saentifioilly  developed  predsion-guided  weapons  and  unmanned  aerial  vehides  help  fight  terrorism  around  the  globe. 

H  owever,  A  ir  Force  leaders  are  battling  a  shortage  of  the  very  engineers  and  stientists  who  created  this  weaponry. 


The  United  States  Air  Force  (USAF)  is 
authorized  to  employ  13,300  military 
and  civilian  engineers  and  scientists. 
However,  the  service  is  short  about  2,700 
positions,  or  about  20  percent,  according 
to  Scott  McLennan,  Air  Force  Materiel 
Command  (AFMC)  system  integration 
engineer.  T hat  is,  if  the  USA F  only  had  to 
fill  current  vacancies. 

Another  problem  is  also  looming,  says 
G  en.  Lester  Lyles,  AFMC  commander.  A 
decade  of  downsizing  and  hiring  freezes 
has  made  almost  70  percent  of  its  civilian 
workforce,  including  engineers  and  scien¬ 
tists,  eligible  for  retirement  in  the  next 
five  to  seven  years.  This  particularly  con¬ 
cerns  the  AFMC  because  it  employs  the 
lion's  share  of  Air  Force  engineers  and 
scientists. 

James  Papa,  AFMC  Engineering  and 
Technical  Management  director,  reiter¬ 
ates  this  concern:  "If  we  do  nothing, 
we're  going  to  see  the  whole  problem 
aggravated  by  a  continuing  exodus  of  our 
senior  people,  and  no  seed  com  to  bring 
in  behind  them." 

Another  hurdle  that  AFMC  and  Air 
Force  officials  have  to  clear  is  competi¬ 
tion  for  retaining  engineers  and  scientists 
due  to  their  demand  in  the  outside  com¬ 
mercial  sector,  says  Papa.  The  nation  as  a 
whole  has  experienced  lower  and  lower 
numbers  of  engineers  coming  out  of  col¬ 
leges  so  engineers  and  scientists  are 
becoming  very  valuable  commodities,  he 
says.  "As  a  nation,  we're  going  to  be  con¬ 
stantly  fighting  over  a  limited  resource.  In 
the  case  of  the  Air  Force,  we’re  going  to 
be  in  the  middle  of  that  battle  for  talent." 

If  these  trends  are  left  unchecked, 
says  Lyles,  it  could  pose  a  possible  readi¬ 
ness  problem  for  AFMC  and  the  Air 
Force.  Losing  its  homegrown  scientific 
and  engineering  capabilities  could  force 
the  world’s  most  prominent  air  power  to 
contract  out  some  of  those  needs,  he 
warns. 

"In  AFMC,  our  mission  is  to  provide 
the  tools  for  the  warfighter,"  says  Lyles. 
"If  we're  not  able  to  meet  and  understand 
the  needs  of  the  warfighter  with  our  own 
organic  capabilities,  we're  not  going  to  be 


as  well  off  as  we  need  to  be.  If  we  have 
to  contract  it  out,  I  think  we're  going  to 
lose.  Whether  it's  in  terms  of  dollars  or 
the  linkage  to  the  warfighters  and  the  rest 
of  the  Air  Force,  I  think  we  will  definite¬ 
ly  lose." 

Papa  agrees,  saying,  "We're  going  to 
be  taking  on  more  and  more  risk  of  our 
development  programs  failing  without 
proper  oversight  from  our  own  organic 
workforce.  We’re  going  to  be  increasing 
the  cost  of  doing  business  in  some  cases 
by  having  to  contract  out  some  of  our 
engineering  support.  If  we  don't  maintain 


our  own  organic  capability  to  oversee  the 
people  we're  asking  to  build  our  systems, 
we  lose  the  expertise  to  define  what  our 
systems  ought  to  be,  and  to  make  sure 
they're  done  properly.  Then  we'll  wind  up 
with  systems  that  don’t  meet  cost  or 
schedule  or  have  performance  problems. 

"It’s  through  the  scientist  and  engi¬ 
neer  corps  that  we  sustain  what's  very 
important  -  technological  dominance  on 
the  battlefield,"  Papa  says.  "It  goes 
beyond  just  producing  state-of-the-art 
systems.  We  need  to  have  a  robust  engi¬ 
neer  and  scientist  corps  to  be  on  the  lead¬ 
ing  edge  and  stay  ahead  of  our  adver¬ 
saries.” 

Papa  says  that  if  the  shortage  goes 
unchecked,  it  could  pose  a  readiness  issue 
of  sorts  for  America's  warfighters.  "With 
current  vacancies  and  a  large  number  of 
retirements  in  the  next  half  decade 
potentially  deteriorating  the  weapons 
acquisition  and  oversight  process,  we're 
not  at  the  point  we'd  like  to  be,  and  that 
could  ripple  out  to  the  field." 


The  Solution 

To  help  bring  the  situation  to  the  fore¬ 
front  of  the  Air  Force's,  the  command 
leaders’,  and  everyone  else’s  minds,  and  to 
find  solutions,  Lyles  declared  2002  as  the 
"Year  of  the  Engineer  and  Scientist”  - 
more  commonly  know  by  the  acronym 
YES. 

The  hope  is  that  this  initiative  will 
remind  everyone  that  engineers  and  scien¬ 
tists  take  concepts  and  ideas  borne  in  lab¬ 
oratories  and  turn  them  into  active  and 
working  weapon  systems,  Papa  says. 
"Then  they'll  sustain  those  systems  on 


through  aging  and  retirement."  Part  of 
AFMC's  YES  initiative  is  designed  to 
focus  the  Air  Force’s  attention  at  all  levels 
of  the  problem.  Command  officials  are 
aiming  at  the  following  three  main  engi¬ 
neering  and  scientific  recruiting  areas: 
workforce  training  and  development, 
workforce  size  and  mix,  and  motivation, 
according  to  Papa.  "We're  currently  work¬ 
ing  initiatives  and  legislation  in  all  these 
areas,"  he  says.  "It's  just  going  to  take 
some  time  to  get  what  we  need  in  place, 
and  up  and  running." 

For  people  considering  engineering 
and  scientific  work  for  the  Air  Force,  Papa 
says  there  are  a  lot  of  opportunities  avail¬ 
able.  People  in  these  fields  are  involved  in 
leading  edge  activity  and  get  increased 
responsibility  sooner  in  their  careers,  he 
says.  They  also  get  involved  in  some  very 
exciting  things  and  contribute  to  the  coun¬ 
try’s  strength,  well-being,  and  military 
power. 

"We’re  never  going  to  offer  the  kinds 
of  opportunities  like  stock  options  and 


"In  AFM  C  [Air  Force  M  ateriel  Command],  our 
mission  is  to  provide  the  tools  for  the  warfighter.  If 
we're  not  able  to  meet  and  understand  the  needs 
of  the  warfighter  with  our  own  organic  capabilities, 
we're  not  going  to  be  as  well  off  as  we  need  to  be." 

—  Gen.  Lester  L .  Lyles, AFM  C  commander 
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gigantic  six- figure  salaries  that  maybe 
young  people  feel  they  can  have  in  the 
dot-com  world  and  other  higher  risk  busi¬ 
nesses/'  Papa  says.  "But  there  are  a  large 
number  of  folks  who  find  working  for  the 
Air  Force  a  rewarding  career,  and  they  are 
the  kind  of  folks  we're  looking  for." 

Workforce  training  and  development 
has  a  three-pronged  approach  to  mapping 
out  the  engineers'  and  scientists'  career 
path,  says  Papa.  They  look  at  what  kinds 
of  experience  engineers  and  scientists 
should  have  in  their  career;  what  kind  of 
training  they  should  have,  and  when  they 
should  have  it;  along  with  what  kind  of 
career  paths  and  promotion  potential  they 
should  have. 

"If  there  are  any  obstacles  to  engineers 
and  scientists  advancing  in  those  career 
paths,  we  need  to  find  ways  to  solve 
those,"  he  says.  The  AFMC  initiatives  to 
attack  those  obstacles  include  increased 
educational  opportunities  and  improve¬ 
ments  in  career  development  for  military 
engineering  officers,  and  making  sure 
there  is  consistency  in  what  is  expected  of 
them  in  terms  of  time  spent  getting  edu¬ 
cation  for  promotion,  he  says. 

The  motivation  area  deals  with  making 
sure  engineers  and  scientists  are  recog¬ 
nized  for  their  accomplishments  and  pro¬ 
vided  fair  compensation,  Papa  says. 
"We've  looked  at  market  comparisons  and 
what  engineers  in  industry  are  receiving  in 
terms  of  starting  salaries  and  middle 
salaries,  and  there’s  a  gap  there,"  he  says. 
"We're  trying  to  work  the  funding  process 
with  the  air  staff  in  building  initiatives  for 
recruiting  and  retention  bonuses  and 
salary  adjustments  that  would  make  things 
more  in  line  with  the  market  we  are  com¬ 
peting  in  for  engineers  and  scientists." 
Workforce  size  and  mix  involves  having  a 
good  handle  on  what  the  command  and 
Air  Force  requirements  are  for  engineers 
and  scientists. 

Conclusion 

While  the  AFMC  is  eleven  months  into 
the  Year  of  the  Engineer  and  Scientist, 
Papa  says  it  is  still  too  early  to  tell  what 
impact  the  initiative  has  had  on  the  prob¬ 
lem.  "It  takes  a  while  to  understand 
whether  we've  turned  anything  around. 
But  we're  anticipating  that  by  next  year 
we’ll  be  able  to  have  a  way  to  look  back 
and  see  if  anything  has  improved,"  he 
says. 

To  make  sure  enough  emphasis  is 
placed  on  the  problem  and  that  solutions 
are  reached,  Lyles  says  AFMC's  Year  of 
the  Engineer  and  Scientist  will  continue 
into  2003> 
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Air  Force  Materiel  Command  Encpneersand  Scientists 

Leif  E .  Peterson 
A  ir  Force  Materiel  Command 

Senior  leadership  within  the  A  irForoe  Materiel  Command  (AFMC)  as  well  as  the  A  ir  Force  has  emphasized  initiatives  to 
recruit,  retain,  and  develop  hicjhly  sk  illed  and  k  nowledgeable  engineers  and  scientists  oapable  of  meeting  the  challenges  of  the 
21st  century.  TheAFMC,  which  employs  about  70  percent  of  the  total  A  ir  Foroe  engineering  occupation,  is  committed  to 
pursuing  every  avenue  available  to  ensure  that  it  acts  on  all  the  appropriate  initiatives  to  tak  e  care  of  this  critical  part  of  our 
workforce. 


One  of  the  Air  Force  Materiel 
Command’s  (AFMC)  key  objectives  is 
to  continue  its  crucial  leadership  role  in 
technology.  The  AFMC  is  a  champion  for 
science  and  technology,  becoming  the 
advocate  and  ally  for  leveraging  new  tech¬ 
nologies.  Its  science  and  engineering  (S&E) 
workforce  is  having  a  tremendous  impact 
on  everything  it  does  in  the  Air  Force,  both 
what  is  currently  in  the  hands  of  our 
warfighters  and  what  will  be  fielded  in  the 
future.  It  is  these  talented  individuals  who 
will  enable  continuing  world-class  technol¬ 
ogy  dominance. 

Unfortunately,  the  extensive  downsizing 
the  AFMC  experienced  during  the  past  11 
years  has  severely  weakened  the  health  of 
the  civilian  force  and  challenges  its  ability  to 
meet  future  mission  challenges.  To  meet  the 
needs  of  an  increasingly  technical  aero¬ 
space  mission,  we  need  to  balance  the  mix 
of  junior,  mid-level,  and  senior  civilians  in 
the  proper  engineering  skills.  In  order  to 
achieve  this  goal,  this  command  is  faced 
with  multiple  challenges  in  recruitment  and 
retention  of  highly  skilled  engineers. 

Within  the  AFMC,  there  are  approxi¬ 
mately  10,580  S&E  positions,  which  make 
up  about  70  percent  of  the  total  Air  Force 
S&E  population1.  The  AFMC’s  S&E  work¬ 
force  is  82  percent  civilian  and  18  percent 
military.  While  its  current  civilian  manning 
seems  to  be  healthy,  it  must  take  a  long, 
hard  look  at  the  future. 

By  2007,  51  percent  of  the  AFMC's 
S&E  workforce  will  be  eligible  for  retire¬ 
ment.  While  not  all  will  retire,  historical 
trends  indicate  that  approximately  20  per¬ 
cent  of  those  eligible  to  retire  will  do  so  the 
year  they  become  eligible.  In  addition,  the 
AFMC  is  competing  with  the  private  sector, 
which  entices  both  potential  recruits  as  well 
as  its  existing  workforce  with  financial  and 
quality-  of-life  incentives.  TheAFMC  is  pro¬ 
jecting  that  it  will  need  to  hire  approximate¬ 
ly  3,300  civilian  engineers  and  scientists  in 
the  next  few  years  to  help  fill  real  and 
potential  gaps. 

In  an  effort  to  prevent  a  potential  crisis, 
the  AFMC  has  engaged  in  a  robust  recruit¬ 
ment  and  retention  effort.  Its  initial 


approach  to  the  problem  will  emphasize 
recruitment  and  retention  bonuses,  and 
explore  the  possibility  of  increases  in  spe¬ 
cial  salary  rates  for  S&Es.  Other  financial 
appeals  may  include  paying  off  student 
loans  and  covering  the  costs  for  further 
education.  Non-pay  issues  include  a  com¬ 
mand-wide  recruitment  program  that 
entails  establishing  a  public  Web  site  that 
would  be  a  one-stop  shopping  concept, 
which  would  link  all  of  our  centers'  recruit¬ 
ment  efforts  to  one  site.  We  have  also 
launched  a  standard  entrance  and  exit  sur¬ 
vey.  These  survey  tools  will  capture  both 
the  organization’s  health  and  shortcomings 
in  its  recruiting  and  retention  effectiveness. 

In  addition,  the  Air  Force  is  looking  to 
place  more  emphasis  on  the  civilian  work¬ 
force  through  a  marketing  plan  that  would 
create  a  total-force  inclusive  marketing  pro¬ 
gram.  This  program  would  include  using  a 
civilian  element  in  the  Air  Force's  marketing 
efforts  aimed  at  fostering  a  sense  of  mis¬ 
sion  and  purpose  in  all  Air  Force  personnel. 

Furthermore,  there  are  several  things 
the  AFMC  is  attempting  to  put  in  place  to 
transfer  individuals’  corporate  knowledge 
prior  to  them  retiring.  First,  we  are  aggres¬ 
sively  pursuing  legislation  to  introduce 
phased  retirement  to  the  workforce.  Phased 
retirement  would  allow  individuals  to  retire 
and  then  come  back  to  work  on  a  part-time 
schedule  to  help  develop  new  recruits. 
Currently,  such  individuals  are  penalized 
since  their  salary  is  offset  by  their  annuity. 
This  means  it  is  unattractive  for  senior  exec¬ 
utives  who  may  want  to  work  fewer  hours 
to  consider  returning  to  the  federal  govern¬ 
ment.  There  is  also  a  provision  for  gaming  a 
waiver  to  this  requirement.  It  now  requires 
Office  of  Personnel  Management  approval; 
we  are  hopeful  the  waiver  approval  level  will 
be  lowered  to  the  components. 

While  we  are  making  positive  steps 
toward  changes  in  legislation  and  policy, 
these  initiatives  are  currently  in  the  discus¬ 
sion  stage  and  at  the  present  time,  no  deci¬ 
sion  has  been  made  to  implement  any  of 
these  ideas.  In  addition,  we  are  also  encour¬ 
aging  our  organizations  to  establish  or 
expand  the  existing  mentoring  program  to 


place  new  recruits  with  someone  who  can 
foster  their  knowledge,  skills,  and  abilities. 

Senior  leaders  within  the  AFMC,  as  well 
as  the  Air  Force,  have  emphasized  initia¬ 
tives  to  "recruit,  retain,  and  develop  highly 
skilled  and  knowledgeable  technical  profes¬ 
sionals."  Within  the  AFMC,  we  are  pursu¬ 
ing  every  avenue  available  to  ensure  we  are 
taking  on  all  the  appropriate  initiatives  to 
take  care  of  this  critical  part  of  our  work- 
force.4 

Note 

1.  Demographic  data  used  in  this  article 
are  drawn  from  the  Headquarters  Air 
Force  file  and  the  Air  Force  Materiel 
Command,  "AFMC’s  Scientists  & 
Engineers,"  Leading  Edge  Oct.  2001. 

About  the  Author 

Leif  E.  Peterson  is 

director,  Civilian  Per¬ 
sonnel  and  Programs 
Division  at  Headquar¬ 
ters  Air  Force  Materiel 
Command  Wright- 
Patterson  Air  Force  Base, 
Ohio.  He  previously  served  as  chief  of 
Staffing,  Development,  and  Equal 
Employment  Opportunity  Division  at 
the  Pentagon  in  Washington  D.C.,  and  as 
director  of  Civilian  Personnel  at  Air 
Combat  Command,  Langley  Air  Force 
Base,  Virginia.  His  awards  include  two 
decorations  for  exceptional  civilian  serv¬ 
ice,  one  meritorious  civilian  service 
award,  and  selection  into  the  Defense 
Leadership  and  Management  Program. 
Peterson  has  a  master's  degree  from 
Loyola  University,  Chicago. 

HQ  AFMC /D PC 

4375  Chidaw  Road,  Room  N208 

W  ric^it-Patterson  AFB,  OH 

45433-5006 

Phone:(937)257-3732 

Fax:(937)257-3928 

E-mail:  leif.peterson@wpafbbaf.mil 


6  Crosstalk  The  Journal  of  Defense  Software  Engineering 


D  ecember  2002 


A  rmyT ransformation: 

Uniformed  Army  Scientists  and  Engineers 

Lt.  Col.  Bairy  L.  Shoop  and  Lt.  Col.  Kenneth  L.  Alford 

U.S.A  rmy 

The  Chief  of  Staff  of  the  A  rmy  G  eneral  E  ricK.  Shinseki  recently  approved  in  principle  the  creation  of  the  U  niformed 
A  rmy  Scientist  and  E  ngineer  (UA  S&  E )  officer  functional  arm.  This  artide  discusses  the  background,  implications,  and 
advantages  assoaated  with  this  new  officer  career  path.  The  UA  S&  E  functional  area  will  provide  the  A  rmy  with  a  core 
population  of  officers  who  possess  spedalized  expertise  to  help  the  A  rmy  make  informed  deasions  and  integrate  technology 
to  improve  our  ability  to  defend  the  nation. 


t f  T"1  he  nation  that  will  insist  on  draw- 

1  ing  a  broad  line  of  demarcation 
between  its  fighting  man  and  the  thinking 
man  is  liable  to  have  its  fighting  done  by 
fools  and  its  thinking  done  by  cowards." 

—  Sir  William  Francis  Butler 

We  live  in  a  society  immersed  in  and 
dependent  on  technological  innovation. 
The  U.S.  Army  represents  a  microcosm 
of  this  society  and  has  been  and  contin¬ 
ues  to  be  one  of  the  largest  users  of 
widely  diverse  and  advanced  technology 
within  the  armed  forces  of  the  United 
States.  The  Army  is  currently  undertaking 
sweeping  changes  in  its  force  structure, 
transforming  into  a  more  strategically 
responsive,  full-spectrum  force  that  is  a 
lighter,  more  lethal,  and  network-centric 
force  that  achieves  these  increased  capa¬ 
bilities  by  leveraging  advanced  technolo¬ 
gy  innovation. 

This  Army  transformation  is  heavily 
invested  in  technology  to  lighten  the 
force  while  increasing  the  lethality  and 
survivability  necessary  for  full-spectrum 
dominance.  The  general  categories  of 
technological  innovations  that  are  being 
leveraged  include  computers,  communi¬ 
cations,  network  technologies  for  the  net- 
work-centric  component,  advanced  and 
distributed  sensors  to  provide  improved 
multi- spectral  sensing  capabilities,  com¬ 
posite  materials  that  reduce  the  overall 
weight  while  maintaining  or  improving 
the  capabilities  of  the  protective  armor, 
electric  and  hybrid  power  systems  for 
propulsion  and  weapons,  and  many  oth¬ 
ers. 

As  an  institution,  the  Army  needs  a 
cadre  of  experts  in  science  and  technolo¬ 
gy  to  fully  optimize  the  capabilities  of  the 
force  and  to  understand  the  potential  of 
future  technologies. 

The  Army's  new  Officer  Personnel 
Management  System  (OPMS  III,  former¬ 
ly  referred  to  as  OPMS  XXI)  provides 
the  mechanism  to  allow  specialization 
within  career  fields.  OPMS  III  has  been 
implemented  recently  and  is  in  marked 


contrast  to  the  way  the  Army  has  histori¬ 
cally  managed  officer  specialization  and 
career  progression.  Officers  can  special¬ 
ize  in  Army  operations,  operational  sup¬ 
port,  information  operations,  and  institu¬ 
tional  support.  OPMS  III  provides  the 
mechanism  for  a  viable  officer  technical 
career  progression. 

G  en.  Paul  Kern,  commanding  general 
of  the  Army  Materiel  Command,  has 
been  instrumental  in  the  creation  of  a 
viable  career  track  for  uniformed  Army 
engineers  and  scientists.  As  he  recently 


" There  is  a  tremendous 
capability  when  you  have 
the  operational 
experience  of  an  officer 
and  the  technical 
training  that  allows  a 
person  to  see  what  is  in 
the  future. " 

noted,  "There  is  a  tremendous  capability 
when  you  have  the  operational  experi¬ 
ence  of  an  officer  and  the  technical  train¬ 
ing  that  allows  a  person  to  see  what  is  in 
the  future”  [1]. 

To  be  successful,  the  Army  transfor¬ 
mation  requires  a  corresponding  change 
in  the  Army  officer  personnel  system  that 
includes  a  core  population  of  officers 
who  focus  on  the  science  and  technology 
that  shapes  the  modem  battlefield  and 
the  Army  force  structure.  The  recently 
approved  in  principle,  Uniformed  Army 
Scientist  and  Engineer  (UAS&E)  func¬ 
tional  area  will  provide  a  dedicated  cadre 
of  experts  to  support  the  Army's  scien¬ 
tific  and  engineering  needs  for  the  pres¬ 
ent  transformation  and  future  technolog¬ 
ical  evolutions  and  transformations. 


To  accomplish  the  required  transfor¬ 
mation  in  the  officer  corps,  the  Army  has 
created  this  new  functional  area  to  sup¬ 
port  a  core  population  of  Army  engi¬ 
neers  and  scientists  educated  in  the 
applied  physical  sciences.  This  functional 
area  will  include  officers  with  advanced 
degrees  in  numerous  scientific  and  engi¬ 
neering  disciplines,  including  but  not  lim¬ 
ited  to  the  following: 

•  Aeronautical  Engineering. 

•  Applied  Mathematics. 

•  Biochemistry. 

•  Chemistry. 

•  Computer  Science. 

•  Electrical  Engineering. 

•  Mechanical  Engineering. 

•  Physics. 

This  functional  area  will  require 
approximately  100  officers  from  the 
grade  of  major  (0-4)  through  colonel 
(0-6)  who  possess  master's  of  science 
and  doctorate  degrees  in  these  and  other 
selected  science  and  engineering  disci¬ 
plines.  These  officers  will  provide  a  core 
population  of  officers  to  serve  as  engi¬ 
neers  and  scientists  in  Army  and 
D  epartment  of  D  efense  (D  oD )  laborato¬ 
ries;  the  new  Research,  Development, 
and  Engineering  (RDE)  Command;  the 
Army  staff  and  joint  staff;  and  in  key 
advisory  positions  throughout  the  Army 
and  DoD. 

Sample  UAS&E  duty  positions 
include  scientists,  engineers,  program 
managers,  and  advisors  within  the  new 
RDE  Command,  Training,  and  Doctrine 
Command  Battle  Labs;  Department  of 
the  Army  and  joint  staff  positions;  and 
program  managers  at  the  Defense 
Advanced  Research  Projects  Agency. 

The  UAS&E  will  provide  a  dedicated 
cadre  of  experts  to  support  the  Army's 
scientific  and  engineering  needs.  UAS&E 
officers  will  possess  the  field  experience 
necessary  to  understand  the  unique  envi¬ 
ronment,  operational  characteristics,  and 
the  technological  needs  of  the  Army. 

UAS&E  officers  will  possess 
advanced  academic  credentials  and  will 
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have  developed  expertise  through  pro¬ 
gressive  science  and  engineering  assign¬ 
ments  and  will  be  gualified  to  contribute 
to  science  and  technology  research, 
advice,  and  policy  development. 
Functional  area  designation  and  career 
field  designation  for  the  UAS&E  func¬ 
tional  area  will  be  the  same  as  those  cur¬ 
rently  used  for  the  Army  Acguisition 
Corps  and  Foreign  Area  Officer  func¬ 
tional  areas  within  the  Army’s  operations 
support  career  field. 

Historical  Background 

The  idea  that  the  application  of  the  mili¬ 
tary  instrument  of  power  in  the  conduct 
of  war  rests  in  a  body  of  knowledge  that 
could  be  studied  and  mastered  by  those 
in  the  profession  of  arms  is  a  relatively 
recent  concept. 

During  the  16th  century,  the  officers 
who  led  armies  into  battle  did  not  receive 
any  special  training  or  education  in 
warfighting.  Instead,  they  received  their 
commissions  as  a  result  of  aristocracy, 
heredity,  or  wealth.  At  the  turn  of  the 


17th  century,  advances  in  technology 
first  changed  the  military's  requirements 
for  specialized  education.  Navigation, 
artillery,  fortifications,  and  engineering 
[2]  were  all  subjects  first  studied  by  offi¬ 
cers  in  order  to  become  more  effective 
leaders  in  the  military  profession. 

It  can  be  argued  that  officer  educa¬ 
tion  is,  in  fact,  the  cornerstone  of  the 
arms  profession.  It  is  the  responsibility 
of  the  military  to  continually  develop  and 
integrate  new  and  improved  methods  of 
warfare  as  a  way  of  achieving  superior 
means  to  conduct  and  win  wars.  To  be 
effective  in  the  process  of  adapting  and 
adopting  new  technologies,  however, 
requires  military  leaders  who  are  imagi¬ 
native  and  innovative.  Education  enables 
informed  and  creative  leadership. 

Officer  education  has  long  been  a 
focus  of  both  individuals  and  study 
groups.  The  first-prize  papers  awarded 
for  contributions  to  the  "Proceedings  of 
the  U.S.  Naval  Institute”  in  1879,  for 
example,  were  on  the  subject  of  officer 
education  [3]. 


In  1996,  an  Army  Science  Board 
study  titled  "The  Science  and 
Engineering  Requirements  for  Military 
Officers  and  Civilian  Personnel  in  the 
High  Tech  Army  of  Today  and 
Tomorrow"  focused  on  the  need  for 
increased  officer  technical  competency. 
This  study  concluded  the  following: 

...  the  Army’s  reliance  on  modem 
weapon  systems  and  technology  has 
been  growing,  its  cadre  of  technol¬ 
ogy-literate  line  officers  and  science, 
math,  and  engineering  (SM&E)- 
educated  officers  has  been  reduced. 

[4] 

Additional  background  information 
on  this  topic  [5]  is  available  in  the  sidebar 
that  accompanies  this  article. 

In  the  current  and  future  military 
environment,  there  exists  a  changed  rela¬ 
tionship  between  officers  and  technolo¬ 
gy.  Firepower  and  maneuverability  previ¬ 
ously  defined  the  realm  of  officer  com¬ 
petencies.  The  American  way  of  war  and 
the  relationship  between  systems 
engaged  in  warfare  on  the  modem  battle¬ 
field  has  fundamentally  changed  as  a 
result  of  modem  technology. 

Scientific  Competency 

Modem  technological  marvels  provide 
instant  access  to  work,  family  and 
resources  almost  anywhere  in  the  world, 
and  have  fundamentally  changed  how 
people  interact.  Yet  never  before  have  we 
become  so  distant  from,  and  at  the  same 
time  ignorant  of,  the  fundamental  sci¬ 
ence  that  enables  this  technology. 
Technical  illiteracy  is  an  epidemic  that 
plagues  modem  society. 

Today  individuals  can  rely  upon  engi¬ 
neers  and  scientists  to  provide  more 
capable  innovations.  Within  the  armed 
forces,  the  tactics  and  doctrines  to 
employ  these  technologically  advanced 
weapon  systems  are  developed  by  the 
military  themselves.  A  lack  of  under¬ 
standing  of  science  and  technology  is  an 
inconvenience  for  civilians,  but  it  can  be 
fatal  on  the  battlefield. 

It  is  neither  practical  nor  desirable 
that  every  officer  in  the  armed  forces 
attempt  to  understand  all  of  the  science 
and  technology  that  supports  our  mod¬ 
em  military.  The  UAS&E  functional  area 
will  provide  the  Army  with  a  small  group 
of  officers  who  possess  the  specialized 
technical  skills  and  understanding  neces¬ 
sary  to  help  the  armed  forces  make 
informed  decisions  and  integrate  tech¬ 
nology  to  improve  our  ability  to  defend 
the  nation. 


Table  1:  Typical  UA  S&  E  30-Year  C areer  Progression 


Uniformed  Army  Scientist  and  Engineer  Career  Progression 

Years  of 
Service 

Duty  Assignment 

0 

•  Commissioned  as  a  second  lieutenant. 

•  Attends  the  Infantry  Officer  Basic  Course. 

1-3 

•  Promoted  to  first  lieutenant. 

•  Serves  as  a  platoon  leader. 

•  Promoted  to  captain. 

4 

•  Attends  the  Infantry  Captains  Career  Course. 

4-7 

•  Serves  as  a  company  commander  and  possibly  in  a  staff  position. 

7 

•  Accessed  into  the  Uniformed  Army  Scientist  and  Engineer  (UAS&E) 
functional  area. 

7-9 

•  Attends  advanced  civil  schooling  and  earns  a  master's  of  science 
degree  in  mechanical  engineering. 

9-10 

•  Completes  the  Command  and  General  Staff  Officer  Course 
(either  in  residence  or  by  correspondence). 

10-13 

•  Serves  in  a  UAS&E  branch-qualifying  duty  position  (for  example,  as  a 
research  scientist  or  instructor  at  the  United  States  Military  Academy). 

•  Promoted  to  major. 

13-16 

•  Attends  advanced  civil  schooling  and  earns  a  doctorate  in 
in  mechanical  engineering. 

16-19 

•  Serves  in  a  UAS&E  duty  position  (for  example,  as  a  technical 
advisor  in  the  Mounted  Maneuver  BattleSpace  Lab  within  the 

Training  and  Doctrine  Command). 

•  Promoted  to  lieutenant  colonel. 

19-22 

•  Serves  in  a  UAS&E  duty  position  (for  example,  as  a  deputy 
director  in  the  Research,  Development,  and  Engineering  Command). 

22 

•  Attends  Senior  Service  College. 

•  Promoted  to  colonel. 

23-30 

•  Serves  in  senior  UAS&E  duty  positions  (for  example,  as  a  science 
advisor  to  the  commander,  Southcom  or  as  an  Army  or  Defense 
Science  Board  member). 
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The  Quest  for  Uniformed  Army  Scientists 

The  following  is  a  historical  outline  of  the  quest  for  uniformed  army  scientists: 

•  1802  -  President  Thomas  Jefferson  signed  legislation  authorizing  the  creation  of 
the  United  States  Military  Academy  at  West  Point,  N.Y.  West  Point  was  the  first 
engineering  school  in  the  United  States. 

•  19th  Century  -  Most  large  engineering  projects  completed  within  the  United 
States  (including  railroads,  bridges,  harbors,  dams,  and  roads)  benefited  from  the 
direct  participation  of  West  Point  graduates. 

•  1925  -  The  Army  sent  Jimmy  Doolittle  to  the  Massachusetts  Institute  of 
Technology  to  earn  a  doctorate  in  aeronautical  engineering. 

•  World  War  II  -  N umerous  scientists  in  uniform  served  the  nation  and  the  Army. 
For  example,  Lt.  G  oldstine,  who  held  a  doctorate  in  mathematics,  encouraged  the 
Ballistic  Research  Lab  to  work  on  a  digital  electronic  computing  device. 

•  1947  -  Maj.  G  en.  Henry  S.  Aurand,  director  of  Research  and  D  evelopment,  gen¬ 
eral  staff  at  the  War  D  epartment,  tried  to  create  a  corps  of  scientist-officers. 

•  1982  -  The  Army  Science  Board  found  that  40  percent  of  the  officers  working 
in  research,  development,  and  acquisition  positions  for  the  Army  had  no  school¬ 
ing  in  science,  engineering,  or  business.  They  encouraged  the  creation  of  the 
Army's  Technology  Enhancement  Program  (TEP). 

•  1984  -  Lt.  G  Maxwell  Thurman,  Army  deputy  chief  of  staff  for  Personnel, 
directed  the  initiation  of  the  TEP.  Initial  entry  second  lieutenants  were  sent  to 
earn  master’s  of  science  degrees.  Mid-career  majors  were  sent  to  earn  their  doc¬ 
torates  in  science  and  engineering  fields. 

•  1985  -  Brig.  G  en.  Hines,  the  deputy  commanding  general  of  the  Army  Personnel 
Command,  created  a  new  officer  branch  to  manage  officers  in  the  TEP  -  the 
Science  &  Technology  Corps. 

•  1990  -  G  William  Tuttle,  commanding  general  of  the  Army  Materiel 
Command  (AMC),  offered  140  AMC  positions  for  a  Uniformed  Army  Scientist 
Program.  The  D  efense  Acquisition  Workforce  Improvement  Act  was  signed  into 
law. 

•  1991-  G  Gordon  Sullivan,  Army  vice  chief  of  staff,  directed  a  Red  Team 
Analysis  of  the  uniformed  army  scientist  question. 

•  1992  -  Lt.  G  en.  Thomas  Carney,  deputy  chief  of  staff  for  Personnel,  approved 
the  Army  Engineer  and  Scientist  (AES)  program.  The  post-Cold  War  Army 
drawdown  tabled  implementation  of  this  program. 

•  1998-2001  -  Various  Army  organizations  studied  the  feasibility  of  creating  a 
Uniformed  Army  Scientist  and  Engineer  functional  area  for  officers. 

•  2001-  G  Paul  Kern  reintroduced  the  concept  of  a  uniformed  Army  scientist 
program. 

•  2002  -  G  Eric  K.  Shinseki,  Army  chief  of  staff,  approved  in  principle  a 
request  from  Gen.  Paul  Kern,  commanding  general  of  the  Army  Materiel 
Command,  to  create  the  Uniformed  Army  Scientist  and  Engineer  (UAS&E) 
functional  area. 


UAS&E  Career  Profession 

As  currently  envisioned,  the  UAS&E 
functional  area  will  access  Army  officers 
into  the  functional  area  at  about  their 
seventh  year  of  active-duty  service. 
UAS&E  officers  will  be  assessed  into 
their  functional  area  at  the  same  time  as 
their  non- UAS&E  peers. 

To  better  envision  the  UAS&E  func¬ 
tional  area  career  progression,  let  us  con¬ 
sider  the  career  of  a  hypothetical  officer, 
John  Smith,  who  is  commissioned  as  a 
second  lieutenant  in  the  infantry  follow¬ 
ing  the  completion  of  his  undergraduate 
degree  in  mechanical  engineering.  Table  1 
follows  his  career  from  the  time  he  enters 
active  duty  as  a  second  lieutenant  until  he 
retires  as  a  colonel  30  years  later. 

The  UAS&E  career  field  will  provide 
promotion  opportunities  through  the 
rank  of  colonel  and  will  help  improve  the 
Army's  return  on  investment  from  the 
time  and  resources  dedicated  to  provid¬ 
ing  officers  with  advanced  civil  schooling. 

Advantages 

The  Army  can  achieve  the  following  ben¬ 
efits  from  creating  and  supporting  the 
UAS&E  functional  area: 

•  By  supporting  a  core  group  of  tech¬ 
nically  and  tactically  proficient  offi¬ 
cers,  the  Army  can  better  ensure  that 
the  maximum  advantage  is  gained 
from  new  systems  and  equipment. 

•  UAS&E  can  help  the  transformed 
force  achieve  its  full  potential  through 
the  correct  employment  of  advanced 
warfighting  systems  and  technologies. 

•  By  providing  science  advisors  to  sen¬ 
ior-level  commanders,  UAS&E  offi¬ 
cers  can  help  reduce  resistance  to 
change  and  help  decision-makers 
understand  the  benefits  of  properly 
applied  technologies. 

•  It  provides  excellent  incentives  for 
recruiting  and  retaining  science  and 
engineering  professionals. 

•  It  provides  the  Army  with  a  set  of 
honest  brokers. 

•  It  can  help  change  the  Army’s  general 
perceptions  of  technically  oriented 
service. 

Summary 

"If  you  don't  like  change,  you're  going  to 
like  irrelevance  even  less"  [6]. 

—  Gen.  Eric  K.  Shinseki 
Army  Chief  of  Staff 

The  Army  has  recognized  the  need  to 
develop  and  support  a  cadre  of  uni¬ 
formed  experts  in  specialized  scientific 
and  technological  fields  in  order  to  help 
transform  itself.  The  UAS&E  functional 


area  will  help  meet  that  need  by  develop¬ 
ing  future  leaders  for  Army  and  DoD 
research  and  development  organizations 
who  understand  soldiers,  future  tech¬ 
nologies,  and  warfighting. 

This  small  investment  in  officer  per¬ 
sonnel  within  the  Army  will  return  large 
dividends  in  the  future  through  the  effec¬ 
tive  and  efficient  application  of  science 
and  technology  to  the  ever- changing  art 
of  war.4 
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Best  Practices 

A  CMMI  Case  Study: 

Process  Encpneering  vs  Ciitire  and  Leadership 

Jeffrey  L.  Dutton 
Jambs  Sverdrup 

Thesucoess  of  a  Capability  Maturity  Model®  IntegrationSM  (CMMISM)  process  improvement  effort  does  not  just  depend  on 
an  understanding  of  the  CMMI,  a  careful  definition  of  the  standard  process,  innovation  in  process  engineering,  a  reasoned 
selection  of  cost  effective  engineering  technologies,  or  even  a  focused  and  fully  responsive  training  program.  Success  depends  on 
the  core  culture  of  the  mmpany,  and  on  the  murage  and  ability  of  its  leaders.  The  CMMI  requires  that  real  people  in  man¬ 
agement,  engineering,  and  infrastructure  adopt  new  behaviors  and  beliefs.  In  this  environment,  two  lessons  have  emerged:  Core 
culture  is  a  principal  factor  in  achieving  success,  and  "change  leadership"  is  as  important  as  "change  management." 


The  subject  organization  used  in  this 
article1,  Jacobs  Sverdrup’s  Advanced 
Systems  G  roup2,  may  be  a  lot  like  yours:  It 
employs  about  400  people  throughout 
seven  states  and  provides  a  wide  range  of 
engineering  services  and  products  to  all 
four  military  services  and  to  NASA. 

Each  office  has  its  own  field  office 
manager,  representing  an  important  oper¬ 
ational  layer  between  the  senior  manager 
and  projects.  As  a  group,  services  and 
products  are  delivered  in  several  technical 
domains,  from  office  and  weapons  system 
software  to  hardware  development  and 
validation  of  major  weapons  simulations. 

Each  of  seven  major  field  offices  dif¬ 
fers  from  the  other  in  terms  of  customer 
culture,  and  all  projects  differ  in  size,  com¬ 
plexity,  and  duration.  Forty-person,  three- 
year  projects  exist  alongside  two-person, 
12-month  efforts.  Since  the  Capability 
Maturity  Model®  (CMM®)  Integration™ 
(CMMISM)  adoption  effort  had  to  be 
accomplished  with  bottom-line  dollars 
(from  profit),  the  pressure  to  invest 
resources  wisely  and  carefully  was  intense 
from  the  start. 

The  improvement  effort  began  by 
chartering  a  software  engineering  process 
group  (SEPG )  in  February  1999.  The  deci¬ 
sion  was  made  to  adopt  the  CMMI  for 
Software  Engineering  (CMMI-SW)  as  the 
reference  model  (then  published  as 
Version  0.1),  as  opposed  to  the  CMM. 
What  was  the  rationale  for  this  decision? 
Since  the  organization  had  yet  to  adopt 
any  type  of  process  model,  it  seemed  to 
make  little  sense  to  adopt  an  older  model, 
and  then  have  to  upgrade  to  the  newer 
standard  almost  immediately. 

Because  the  organization  was  geo¬ 
graphically  distributed,  the  new  SEPG 
went  about  forming  and  training  distrib¬ 
uted  Process  Action  Teams  (PAT)  to  begin 
the  task  of  adopting  the  process  areas 
within  the  CMMI.  The  idea  was  that  a  dis¬ 
tributed  development  of  the  standard 
process  would  make  a  buy-in  much  easier. 


Each  PAT  was  made  up  of  personnel  from 
at  least  two  of  the  seven  major  offices.  All 
of  the  PATs  then  met  with  the  SEPG  lead 
as  the  organizational  SEPG  on  a  quarterly 
basis.  It  was  supported  by  a  Web  site  that 
provided  workspaces  for  each  PAT,  infor¬ 
mation  and  references  concerning  the 
overall  effort,  and  a  viable  means  of  com¬ 
municating  among  the  PATs. 

"...  we  decided  to 
petition  the  Software 
Engineering  Institute 
(SEI)  to  join  the  CMMI 
Version  1.0  product 
development  team , 
primarily  to  avoid  future 
surprises  in  the  evolution 
of  the  CM  M I  family  of 
models. " 


Unfortunately,  the  distributed  PAT 
approach  was  fraught  with  participation 
and  buy-in  issues  from  the  start  (see 
Organizational  Culture,  page  13).  Several 
solutions  to  the  non-participation  problem 
were  tried,  including  tying  individuals'  per¬ 
formance  evaluations  to  support  for  the 
PATs,  positive  feedback  systems,  a 
newsletter,  and  intense  training  for  the 
SEPG  and  PAT  members.  By  the  time 
CMMI  Version  0.2  was  published  in 
August  1999,  it  was  clear  that  the  fully  dis¬ 
tributed  approach  was  not  going  to  work. 

Then  when  it  was  introduced,  the  single 
process  structure  of  the  CMMI  for  Systems 
Engineering  and  Software  Engineering 
(CMMI-SE/  SW)  Version  0.2  came  as  a 
surprise.  We  took  advantage  of  this  by 


making  three  important  decisions.  First, 
due  to  the  nature  of  the  organization’s 
business  base,  adopting  the  systems  engi¬ 
neering  model  in  conjunction  with  the 
software  engineering  model  offered  a 
major  advantage  because  the  organization 
now  had  the  potential  to  develop  a  true  sin¬ 
gle  process  for  engineering  from  the  start. 
Second,  we  decided  to  reorganize  the  dis¬ 
tributed  SEPG  into  an  Engineering 
Performance  Improvement  Center  (EPIC) 
with  a  core  team  of  two  people  and  field 
office  leads  from  each  of  the  seven  major 
offices.  Third,  we  decided  to  petition  the 
Software  Engineering  Institute  (SEI)  to 
join  the  CMMI  Version  1.0  product  devel¬ 
opment  team,  primarily  to  avoid  future 
surprises  in  the  evolution  of  the  CMMI 
family  of  models. 

With  a  core  team  of  process  engineers 
and  the  support  of  field  office  leads  from 
all  the  major  offices,  EPIC  began  the  task 
of  standard  process  definition  in  earnest. 
The  first  step  EPIC  took  was  to  translate 
the  CMMI-SE/  SW  process  areas  into  core 
processes  that  were  meaningful  to  busi¬ 
ness  operations,  thus  adopting  a  core  process 
architecture  (see  Figure  1,  page  12).  This  was 
done  for  two  reasons.  First,  the  CMMI  was 
still  evolving  in  terms  of  the  number  and 
definition  of  process  areas.  Second,  we 
wanted  to  focus  on  things  that  were 
important  to  the  company. 

Among  other  things,  we  wanted  a  clear 
focus  on  product  engineering,  which  was 
missing  from  the  CMMI.  We  included 
infrastructure  as  a  core  process,  i.e.,  a  recog¬ 
nition  that  adoption  of  the  CMMI  will 
affect  processes  and  technologies  used  by 
business  development,  human  resources, 
training,  information  systems,  and  finan¬ 
cial  management.  We  ultimately  found  a 
life-cycle  framework  in  ISO/IEC  12207 
[1]  that  served  as  a  starting  point  for  our 


®  Capability  Maturity  Model  and  CMM  are  registered  in  the 
U.S.  Patent  and  Trademark  Office. 

SM  Capability  Maturity  Model  Integration  and  CMMI  are  serv¬ 
ice  marks  of  Carnegie  Mellon  University 
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CMMI-SE/SW  L2/L3  PROCESS  AREAS 

Note:  Staged  Maturity  Level  shown  in  parentheses. 
Measurement  and  Analysis  (2)  - 


CORE  PROCESSES 


STANDARD  PROCESS 


Organizational  Training  (3)  - 

Organizational  Process  Focus  (3)  — 
Organizational  Process  Definition  (3) 
Supplier  Agreement  Management  (2) 

Decision  Analysis  and  Resolution  (3) 


Process  and  Product  Quality  Assurance  (2)  ■ 

Project  Planning  (2)  - 

Project  Monitoring  and  Control  (2) - 

Risk  Management  (3)  - 


Integrated  Project  Management  (3) 

Requirements  Management  (2)  - 
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Figure  1:  Organizational  Subsystems 
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core  process  architecture.  In  addition  to 
focusing  our  thinking,  the  core  process 
architecture  insulated  us  from  all  but  the 
most  severe  changes  to  the  CMMI- 
SE/  SW  as  it  evolved  from  Version  0.2. 

Process  Engineering 

Mechanisms  and  Innovations 

During  the  next  two  years,  the  organiza¬ 
tion  defined  the  standard  process  in  six 
major  work  products,  each  with  its  own 
primary  focus  and  internal  customers. 
These  included  the  following: 

•  An  integrated  engineering  handbook 
for  project  managers,  engineers,  and 
management. 

•  An  engineering  performance  improve¬ 
ment  program  plan  for  the  EPIC. 

•  A  process  and  product  quality  assur¬ 
ance  plan  for  quality  assurance. 

•  A  measurement  and  analysis  plan  for 
the  entire  organization. 

•  A  purchasing  manual  for  contract 
managers  and  project  managers. 

•  A  knowledge  management  plan. 

For  our  purposes,  we  defined  knowledge 
management  as  containing  five  specific 
stages  in  the  learning  process:  knowledge 
needs  assessment,  knowledge  assimilation 
or  creation,  knowledge  codification, 
knowledge  transfer,  and  assessment  of 


both  assimilation  and  the  knowledge-man¬ 
agement  process  itself.  The  concept  and 
practice  of  knowledge  management  cre¬ 
ates  alternative  training  solutions,  and 
allows  us  to  start  activities  like  identifica¬ 
tion  of  knowledge  domains  and  develop¬ 
ment  of  knowledge  base  experts. 

The  organization  also  adopted  several 
mechanisms  and  (at  least  to  us)  innova¬ 
tions  that  have  proven  or  are  starting  to 
prove  their  value.  Among  these  are  the  fol¬ 
lowing: 

•  A  life  cycle  that  is  both  flexible  and 
recursive,  allowing  tailoring  to  support 
the  needs  of  the  project  and  the  cus¬ 
tomer. 

•  A  repeatable  tailoring  approach  that 
accommodates  services,  systems,  and 
hardware  and  software  development 
for  small  to  large  project  sizes. 

•  The  use  of  principal  managers  and 
leaders  in  the  organization  to  teach 
critical  courses. 

•  The  early  development  of  an  automat¬ 
ed  measurement  database. 

•  The  development  (later  than  we  want¬ 
ed)  of  a  distributed  work  environment 
to  support  process  engineering  and 
information  sharing. 

Several  of  these  innovations  and 
mechanisms  have  been  the  subject  of  con¬ 


ference  panels  and  the  SEI's  working 
group  efforts  [2,  3, 4], 

We  understood  and  have  reaffirmed 
the  value  of  frequent  external  assessments 
as  a  means  of  refreshing  our  approach, 
clarifying  issues,  and  evolving  the  process 
culture.  We  had  an  external  SEI-author- 
ized  lead  assessor  conduct  four  profiles,  or 
low-end  assessment  requirements  for 
CMMI  (ARC)  Class  B  assessments.  We 
have  also  conducted  one  ARC  Class  B 
assessment  that  was  nearly  a  full  Level  3 
Standard  CMMI  Assessment  Method  for 
Process  Improvement. 

The  results  of  our  ARC  Class  B  were 
that  our  standard  process  was  nearly  com¬ 
plete,  but  project  buy-in  and  institutional¬ 
ization  was  found  to  be  lacking.  The 
assessment  caused  us  to  refocus  our 
knowledge  management  program,  and  to 
add  activities  to  gain  buy-in  at  the  project 
and  organizational-unit  manager  level.  We 
also  had  an  epiphany  as  a  direct  result  of  the 
assessment:  Our  services  thread  in  the  stan¬ 
dard  process  was  not  as  complete  as  it 
needed  to  be. 

In  all  cases,  we  have  found  clarifying 
realizations  that  catapulted  our  under¬ 
standing  and  insight  rapidly  forward.  The 
opportunity  for  organizational  delusion 
(potentially  humorous  when  seen  in  other 
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organizations,  but  not  very  funny  when 
found  in  your  own)  is  too  great  to  not  rely 
on  frequent  outside  counsel.  We  found 
that  frequent  profiles  combined  with  less 
frequent  full  assessments  provided  the 
right  balance  of  value  vs.  cost. 

The  process  engineering  team  went  to 
great  lengths  to  share  all  information 
openly  throughout  the  organization.  A 
continuous  and  proactive  effort  was 
mounted  to  get  buy-in  from  all  levels  of 
the  organization,  including  frequent 
reviews  and  decisions  made  by  the  EPIC 
field  office  leads,  intermediate  and  senior 
management  reviews  through  an  engineer¬ 
ing  management  council,  and  quality 
reviews  of  process  documents.  Most 
importantly,  the  initial  version  of  standard 
process  documentation  was  completed 
and  refined  through  the  full  participation 
of  four  pilot  projects,  which  represented 
small  to  large  software  efforts  and  one 
systems  engineering  effort.  A  significant 
number  of  changes  and  lessons  learned 
from  the  pilot  projects  were  integrated 
into  the  standard  process. 

During  most  of  the  two  years,  the 
organization  also  worked  closely  with  the 
SEI  to  better  understand  the  content  and 
intent  of  the  CMMI-SE/  SW  and  associat¬ 
ed  assessment  and  evaluation  methods.  In 
May  2002,  the  organization  successfully 
passed  the  CMMI-SE/  SW  Level  2 
appraisal. 

Organizational  Culture 

In  some  aspects,  Jacobs  Sverdrup's  organi¬ 
zational  culture  was  like  most  in  the  indus¬ 
try,  yet  markedly  different  in  other  respects 
to  the  industry  average.  There  were  pock¬ 
ets  of  well-developed,  pro  cess- literate 
software  development  projects.  These 
offices  understood  software  life-cycle 
engineering,  the  value  of  configuration 
management,  metrics,  and  quality  assur¬ 
ance.  They  went  about  project  planning  in 
a  repeatable,  meticulous  manner.  At  the 
same  time,  other  projects  at  other  loca¬ 
tions  might  have  difficulty  in  understand¬ 
ing  the  value  of  clearly  specified  require¬ 
ments,  or  in  understanding  the  difference 
between  requirements  analysis  and 
requirements  management. 

A  significant  segment  of  the  organiza¬ 
tion  conducted  engineering  services  that 
did  not  produce  a  typical  hardware  system 
or  software  product.  Some  efforts  provid¬ 
ed  acquisition  support  services;  some  pro¬ 
vided  detailed  validation  of  weapons  sys¬ 
tems  simulations.  These  services  projects 
were  staffed  with  competent  to  excellent 
technical  personnel  and  excellent  project 
managers,  but  they  did  not  reflect  ele¬ 
ments  of  a  life- cycle  engineering  culture. 


In  general,  no  organization-wide  meas¬ 
ures  were  being  collected  or  analyzed  on  a 
routine  basis,  except  for  customer  satisfac¬ 
tion  ratings  and  certain  financial  perform¬ 
ance  measures. 

There  also  existed  a  set  of  organiza¬ 
tional  core  values  that  were  propagated 
and  institutionalized  through  leadership 
example,  training,  and  evaluation  of  office 
and  personal  performance.  These  core  val¬ 
ues  were  assimilated  throughout  the 
organization,  and  provided  a  foundational 
starting  point  for  process  improvement. 
These  core  values  were  comprised  of  the 
following  statements:  "We  are  relation- 
ship-based,"  "People  are  our  greatest 
asset,"  and  "Growth  is  an  imperative." 

The  values  were  adhered  to  and  con¬ 
sidered  in  normal  operations  at  each  level 
of  the  organization.  This  resulted  in  a 

"  The  underlying 
message  was  that 
commonly  held  values 
(processes),  if  strictly 
adhered  to,  offer  real 
potential  for 
organizational  and 
personal  success." 

common  culture  that  exhibited  a  consis¬ 
tent  focus.  The  underlying  message  was 
that  commonly  held  values  (processes),  if 
strictly  adhered  to,  offered  real  potential 
for  organizational  and  personal  success. 
This  core  value  system,  shared  by  every¬ 
one  from  business  and  technical  leaders  to 
project,  intermediate,  and  senior  man¬ 
agers,  provided  the  cultural  foundation  for 
process  improvement. 

Lastly,  the  organization  enjoyed  a 
strong  culture  of  enlightened  leadership. 
Real  and  consistent  effort  was  routinely 
invested  in  defining,  evolving,  and  improv¬ 
ing  leadership  principles  and  practices 
among  senior,  intermediate,  and  project 
leaders.  Distinctions  were  commonly 
made  between  management  and  leader¬ 
ship  principles  and  practices. 

Strong  ethical  principles  were  com¬ 
monly  exercised,  illustrated  by  such  prac¬ 
tices  as  commitment  to  the  long-term 
employment  of  proven  technical  person¬ 
nel,  the  stewardship  of  customer 
resources,  and  a  real  dedication  to  the  real¬ 
ization  of  core  values.  Managers  were 
required  to  value  the  relationship  with  the 


customer  over  the  transactional  value  of 
the  effort.  For  example,  managers  routine¬ 
ly  cared  for  customer  resources  entrusted 
to  the  organization  in  a  way  that  conserved 
their  use  and  provided  visibility  into  the 
way  they  were  expended  on  behalf  of  the 
customer.  Why?  Customers  who  are  treat¬ 
ed  this  way  will  ultimately  turn  over  more 
of  their  resources  to  manage.  During  the 
time  frame  under  consideration,  the  con¬ 
cept  of  operational  excellence  was  added 
as  an  ancillary  core  value. 

Change  Leadership 

The  challenges  to  organizational  leader¬ 
ship  proved  to  be  manyfold,  ranging  from 
developing  a  trusted  relationship  with  the 
organizational  change  agent,  EPIC,  to  sup¬ 
porting  the  many  initiatives  needed  to 
obtain  buy-in  from  all  levels  of  the  organ¬ 
ization. 

It  is  important  to  consider  these  chal¬ 
lenges  carefully.  In  organizations  that  are 
not  yet  organizationally  mature,  leaders 
may  attain  their  positions  through  CMM 
Level  1  skills.  That  is,  it  is  possible  to  attain 
leadership  positions  with  stovepipe  organi¬ 
zational  skills.  If  this  is  the  case  in  the 
organization,  the  prospect  for  successful 
adoption  of  a  rigorous  and  widely  scoped 
model  like  the  CMMI  is  much  less  likely. 
As  an  organization,  we  were  extremely  for¬ 
tunate  that  our  leadership  was  dedicated  to 
the  underlying  principles  of  improvement. 

The  challenges  to  organizational  lead¬ 
ership  were  real,  and  came  from  two 
sources.  First,  leaders  were  faced  with  hav¬ 
ing  to  change  the  way  they  did  business, 
sometimes  in  fairly  uncomfortable  ways. 
They  were  asked  to  alter  or  even  abandon 
tried-and-true  concepts,  attitudes,  and  prac¬ 
tices  that  were,  for  all  they  knew,  the  very 
things  that  got  them  where  they  were. 
Then,  in  this  changing  and  somewhat 
uncomfortable  environment,  leaders  were 
asked  to  deal  with  push  back  (or  resistance) 
from  the  organization. 

Push  back  comes  from  all  levels  of  the 
organization  but  at  different  times  and  for 
different  reasons.  It  is  a  natural  and 
expected  part  of  process  implementation 
and  institutionalization.  The  need  to 
respond  positively  and  proactively  to 
objections  or  criticisms  of  the  evolving 
standard  process  is  extremely  important  to 
buy-in. 

Well-meaning  engineers  and  managers 
sought  out  our  senior  leaders  to  discuss 
problems  and  difficulties  with  the  evolving 
standard  process  and  supporting  technolo¬ 
gies.  This  problem  was  exacerbated  by  the 
nature  of  the  CMMI,  as  the  model  is  intru¬ 
sive  on  the  processes  used  by  organiza¬ 
tional  infrastructure,  including  information 
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technology.  It  was  important  to  rely  on  the 
leadership’s  knowledge  of  the  CMMI,  of 
the  principles  of  process  improvement, 
and  trust  in  the  seminal  abilities  of  the 
change  manager  in  dealing  with  such 
issues. 

The  change  manager  (EPIC  technical 
director)  developed  a  close  and  continuous 
relationship  with  the  senior  leadership.  An 
early  effort  was  made  to  understand  how 
the  business  environment  would  evolve, 
that  information  would  be  shared  across  all 
levels  of  the  organization,  and  that  stan¬ 
dard  processes  would  normally  have  to  be 
followed,  even  by  the  leadership.  The 
problem  is,  these  words  just  did  not  mean 
much  to  an  organization  that  was  just  start¬ 
ing  down  its  quality  path. 

So  our  leadership  was  pretty  much  left 
to  discover  for  itself  how  real  the  CMMI  is. 
The  discovery  process  had  several  layers, 
each  rising  into  view  as  the  one  before  was 
successfully  negotiated.  Discovery  levels 
included  the  following: 

•  The  CMMI  really  does  change  the  way 
every  part  of  the  organization  operates. 

•  The  costs  associated  with  adoption  of 
the  CMMI  are  real  and  cannot  be 
avoided. 

•  Routine  actions  have  to  be  conducted 
in  accordance  with  the  standard 
process,  as  well  as  corrective  and  near¬ 
crisis  actions. 

•  A  CMMI  process  improvement  effort 
is  not  just  another  project,  where  the  work 
products  are  the  most  important  out¬ 
put. 

•  Some  of  the  people  you  have  worked 
with  and  trusted  for  years  will  resist  the 
improvement  effort  for  various  well- 
intentioned  reasons. 

•  A  ssessments  cannot  be  used  to  provide 
feedback  and  evaluate  the  performance 
of  individual  elements  of  the  organiza¬ 
tion. 

•  The  CMMI  process  improvement 
effort  must  be  carefully  aligned  with 
the  goals  of  the  organization  to  make  it 
worthwhile. 

•  The  management  and  leadership  style 
that  has  served  to  bring  leaders  this  far 
in  the  organization  now  must  be  nego¬ 
tiated  with  the  unseen  authors  of  a 
complex  model  they  are  just  beginning 
to  appreciate. 

The  business  instincts,  trust,  and  core 
values  of  the  leadership  are  challenged  in 
this  environment,  and  rightfully  so. 

Conclusion 

So  what  combination  of  elements  does  it 
take  to  succeed  in  adopting  the  CMMI? 
Competent  process  improvement  strata¬ 
gems  and  activities  are  certainly  necessary, 


but  not  sufficient.  Innovation  may  provide 
considerable  additional  value  to  the  organ¬ 
ization,  but  not  if  the  process  improve¬ 
ment  effort  is  terminated  while  the  process 
group  is  busy  innovating.  Organizational 
culture  and  core  values  have  a  considerable 
effect  on  the  probability  of  success  of  the 
CMMI  effort.  And,  because  the  CMMI 
intrudes  on  the  infrastructure  of  an  organ¬ 
ization,  the  potential  impact  of  culture  on 
the  process  improvement  effort  is  magni¬ 
fied. 

There  will  be  bumps  in  the  road.  Some 
heroes  in  the  organization  will  probably 
leave.  It  will  take  longer  and  cost  more  than 
anyone  wants.  Management  and  leadership 
will  be  exposed  to  a  series  of  discoveries  that 
will  be  somewhat  uncomfortable,  and  even 
be  asked  to  continuously  re-examine  the 
values,  beliefs,  and  management/  leader¬ 
ship  techniques  with  which  they  have  suc¬ 
ceeded  so  well  in  the  past.  New  manage¬ 
ment  techniques  will  have  to  be  adopted, 
and  the  discipline  with  which  engineers 
conduct  business  will  be  made  significantly 
more  rigorous.  The  amount  and  detail  of 
continuous  information  sharing  will  increase 
considerably  at  all  levels  of  the  organiza¬ 
tion. 

The  substantive  issues  that  threaten  the 
success  of  a  CMMI  process  improvement 
effort  stem  from  a  single  source:  the  need 
for  every  engineer,  manager,  and  leader  in 
the  organization  to  evolve  in  a  very  pre¬ 
scribed  manner  of  conducting  business. 
The  professional,  hard-working  people 
who  make  up  the  organization  have  to  be 
led  to  believe  that  the  new  way  will  work. 
They  need  to  believe  it  will  not  threaten 
their  careers,  will  not  ultimately  make  their 
jobs  more  difficult,  and  will  allow  them  to 
succeed  within  a  new  framework  that  they 
are  just  beginning  to  understand.  This  task, 
while  difficult,  is  critical  to  success.  It 
requires  business  leaders  who  are  commit¬ 
ted  to  the  fundamental  improvement  of 
their  organization,  who  know  and  trust 
their  people,  and  who  have  the  skills  and 
character  to  lead  people  through  change. ♦ 
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Note 
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*K  Software  ErKpnwrlng  Technology 

TheAFIT  Offers  Software  Continuing  Education 
atYour  Location  at  No  Cost 

Maj.  Brian  G.  Hermann 
U.S.  A  ir  Force 

A  II  our  lives  we  have  heard  stories  and  witnessed  ex  amples  that  show  education  is  the  means  to  improve  our  abilities  and  lives 
in  general.  U  nfortunatdy,  we  seem  to  forget  this  maxim  when  we  enter  the  software  workforce  -  instead  believing  in  fads, 
tools,  and  long  hours.  But  education  truly  is  the  long-term  solution  to  the  D  epartment  of  D  efense's  software  woes,  and  the 
Software  Professional  D  evelopment  Program  is  an  inex  pensive,  flex  ible  way  to  get  state-of-the-art  software  engineering  educa¬ 
tion  right  away.  This  article  ex  plains  the  program  and  reinforces  the  truth  that  education  is  the  answer. 


Like  most  software  engineers  and  man¬ 
agers,  you  are  mired  in  a  never-ending 
battle  to  get  your  project  completed  to  your 
customer's  satisfaction  and  your  boss'  sched¬ 
ule  and  budget.  In  hopes  of  improving  your 
fate,  you  would  like  to  try  some  of  the  new 
technigues  you  have  read  or  heard  about, 
but  first  you  need  more  information.  There 
are  a  number  of  opportunities,  but  where 
will  you  get  your  software  education? 

You  could  go  to  a  local  university  or 
attend  a  commercial  software  training  class. 
Most  likely,  you  do  not  have  time  to  take  a 
leave  from  work  to  finish  your  master's 
degree,  and  your  local  university  is  too  theo¬ 
retical  and  cost  prohibitive.  Commercial 
software  training  is  frequently  expensive  and 
normally  requires  traveling.  So  what  are  your 
options?  You  could  keep  burning  the  candle 
at  both  ends,  buy  stock  in  Maalox,  and  hate 
your  job.  Or  you  could  get  some  practical, 
state-of-the-art  software  engineering  and 
management  education  at  your  location  and 
at  no  cost  to  your  unit.  That  sounds  too 
good  to  be  true  -  how  can  we  offer  that  kind 
of  a  deal? 

In  the  late  1980s,  the  Air  Force  recog¬ 
nized  that  education  was  the  answer  to  the 
software  crisis  and  formed  the  Software 
Professional  D  evelopment  Program  (SPD  P) 
at  the  Air  Force  Institute  of  Technology 
(AFIT).  This  program  -  once  a  training 
requirement  for  software  engineering  offi¬ 
cers  within  the  communications-computer 
systems  career  field  -  continues  to  help 
organizations  combat  poor  quality,  late,  and 
over-budget  software.  As  Air  Force  systems 
increasingly  rely  on  more  complex  software, 
the  need  for  timely  software  engineering 
education  has  increased.  SPD  P  provides  this 
education  -  free  of  charge  -  to  all 
Department  of  Defense  employees.  The 
courses  are  taught  in  distance  learning,  con¬ 
tinuing-education  format  from  the  AFIT’s 
School  of  Systems  and  Logistics  at  Wright- 
Patterson  Air  Force  Base  in  D  ayton,  0  hio. 

A  Custom  Curriculum 

The  SPD  P  program  is  flexible  to  meet  your 


needs.  All  distance-learning  courses  are 
offered  a  la  carte  with  no  prerequisites. 
That  means  you  get  the  knowledge  you 
need,  when  you  need  it.  Table  1  shows 
AFIT's  current  lineup  of  continuing  edu¬ 
cation  software  courses.  This  course  lineup 
represents  the  largest  restructuring  of  the 
SPDP  curriculum  since  its  inception.  In 
addition,  you  can  tailor  a  sequence  of 
classes  for  yourself  or  you  can  complete  a 
series  to  earn  one  or  more  of  our  certifi¬ 
cate  programs  (see  Table  2). 

The  first  two  courses  offer  an  intro¬ 
duction  to  the  software  life  cycle  and 
proven  techniques  to  help  successfully 
manage  a  software  development  or  acqui¬ 
sition  project.  Specific  courses  are  also 
offered  for  each  life-cycle  phase:  require¬ 
ments,  design,  implementation,  and  main¬ 
tenance.  N  ext,  software  testing  and  object- 
oriented  issues  are  explored.  The  two  final 
courses  offer  hands-on  opportunities  to 
put  your  new  capabilities  into  practice. 

Our  customers  told  us  they  wanted 
shorter  courses  to  fit  into  schedules  filled 
with  deadlines  and  deployments.  Each 
SPDP  course  is  three  to  four  weeks  in 


length  with  twice-weekly  lessons.  Missing  a 
live  class  due  to  a  TDY  or  emergency  will 
not  slow  you  down  since  we  can  deliver 
classes  on-demand  using  Internet  video 
streaming,  satellite  transmission,  video¬ 
tape,  Internet  conferencing,  or  CDs.  This 
gives  you  the  option  to  come  to  class  as 
your  schedule  permits. 

While  you  are  taking  classes,  you  will 
get  most  of  your  materials  through  AFIT's 
new  Web-based  learning  management  sys¬ 
tem,  called  Blackboard.  This  system  pro¬ 
vides  a  single,  easy-to-navigate  location  for 
students  to  access  course  materials  and  les¬ 
sons.  Blackboard  also  helps  to  simulate  a 
local  classroom  environment  by  providing 
a  place  to  submit  homework,  take  quizzes, 
and  communicate  with  fellow  students  and 
faculty  online.  The  SPDP  program  works 
not  because  of  technology,  but  because  we 
have  been  careful  to  include  personal  inter¬ 
action  in  the  mix  with  practical  informa¬ 
tion.  The  SPD  P  faculty  deliver  the  lessons 
and  are  available  to  help  you  through  each 
course,  provide  free  consulting  services  for 
you  and  your  organization,  and  can  even 
offer  on-site  workshops  if  your  oiyaniza- 


Table  1:  SPDP  Classes 


Course  Number 

Course  Title 

CSE  480 

Introduction  to  Software  Project  Management 

CSE481 

Software  Systems  Engineering 

CSE  482 

Software  Requirements 

CSE  483 

Software  Design 

CSE  484 

Software  Implementation 

CSE  485 

Software  Systems  Maintenance 

CSE  486 

Verification,  Validation,  and  Testing 

CSE  487 

Fundamentals  of  Object-Oriented  Design 

CSE  488 

Object-Oriented  System  Modeling 

CSE  489 

Advanced  Analysis  and  Design  of  Object-Oriented  Systems 

CSE  496 

Practicum  (In-Residence) 

Table  2:  SPDP  Certificate  Programs 


Certificate 

Required  Courses 

Software  Engineering  Management 

CSE  480  and  481 

Software  Life-Cycle  Development 

CSE  482,  483,  484,  and  485 

Advanced  Software  Development 

CSE  486,  487,  and  488 

Technical  Software  Development 

CSE  489  and  496 
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Coming  Events 


January  27-30 

Reliability  and  M  aintainability 
Sympoaum 
Tampa,  FL 
www.rams.org 

February  10-13 

Commercialization  ofMilitaryand 
Space  Electronics  C onference 
LosAngdes,  CA 

www.cti-us.com/ucmsemain.htm 

February  24-27 

Software  Engineering  Process 
G roup  C onference 

SEPG 

2003 

Boston,  M  A 

www.sei.cmu.edu/sepg/ 

March  24^28 

International  Symposium  on 
Integrated  N etwork  M  anagement 
Colorado  Springs,  CO 
www.im2003.org 

April  8-10 

FOSE  2003 
Washington,  D.C. 
www.fose.com 


April  28-May  1 

SoftwareTechnology  C  onference  2003 

“S“F£^ 

Salt  Lake  City,  UT 
www.stc-online.org 

May  3-10 

International  Conference  on 
Software  Engineering 
Portland,  0  R 

www.icse-conferences.org/2003 

May  6-8 

TechNet  2003 
Washington,  D.C. 
www.technet2003.org 


Workshop  Planning  A  nnouncement 

The  Software  Professional  Development  Program  (SPDP)  faculty  is  working  to  set 
up  the  D  epartment  of  D  efense's  (D  oD )  first-ever  software  engineering  education 
workshop.  G  oals  for  this  meeting  are  to  develop  a  listing  of  educational  and  training 
opportunities  and  to  foster  working  relationships  to  realize  better  and  more  com¬ 
prehensive  educational  programs  to  offer  to  the  D  oD 's  software  workforce.  If  you 
work  in  the  field  of  software  engineering  education  and  training  or  represent  an 
organization  with  a  significant  demand  for  software  engineering  education,  please 
contact  the  SPDP  faculty  to  add  your  organization  to  our  list  of  invitees. 


tion  has  a  large  education  need.  As  an 
added  bonus,  we  provide  free  course  text¬ 
books  for  your  professional  reference 
library. 

Our  only  resident  course,  CSE  496,  is 
offered  at  least  annually  at  the  AFIT’s 
campus  and  provides  students  a  chance  to 
put  all  of  the  SPD  P  techniques  to  work  in 
a  team-based  software  development  proj¬ 
ect.  Students  laud  this  opportunity  as  the 
culmination  of  the  program  and  a  great 
chance  to  try  new  skills  in  a  non-threaten¬ 
ing  environment  while  networking  with 
other  practitioners. 

Your  best  way  out  of  the  software 
death-march  nightmare  is  to  invest  some 
time  improving  your  abilities.  Fortunately, 
you  do  not  have  to  go  far  or  spend  a  lot  of 
money.  Our  faculty  is  here  to  help.  Most 
SPDP  students  see  improvement  during 
their  current  projects.  ♦ 
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Getting  Started 

G  et  started  today  by  either  filling  out  an 
application  on  our  Web  site  at 
chttp :/  /  ls.afit.edu/  spdp>,  e-mailing  the 
faculty  at  spdp@afit.edu,  or  contacting 
Candace  Barker  at  (937)  255-7777 
x3319,  or  DSN  785-7777  x3319. 


Department  of  the  Air  Force 
AFIT/LSS  Building  641 
2950  P  Street 

W  right-Patterson  A FB,  O  H  45433 
Phone:  (937)  255-7777  ext.  3131 
DSN :  785-7777  ext.  3131 
Fax:  (937)  656-4654 
DSN:  986-4654 

E-mail:  brian.hermann@afit.edu 


Letter  to  the  Editor 


DearCrossTal  k  Editor, 

Hello  and  thanks  for  another  informa- 
tiveCrossTal  k  (July  2002)  and  espe¬ 
cially  for  the  Open  Forum  article  "JAD 
on  a  Shoestring  Budget"  by  Dr.  Mario  J. 
Spina  and  John  A.  Rolando. 

In  my  experience  facilitating  many 
JAD -like  workshops,  this  approach  to 
requirements  elicitation  saves  time  and 
money  and  helps  clients  and  technical 
staff  get  the  right  stuff,  fast.  Best  of  all, 
the  collaboration  that  is  the  hallmark  of 
these  sessions  sets  the  stage  for  solid 
client-IT  relationships  so  necessary  for 
successful  projects. 


The  authors  provided  a  helpful  set  of 
additional  reading  and  Web  sites,  to 
which  I  would  like  to  add  my  own: 
<www.ebgconsulting.com/  publica 
tions.html#jad>. 

Please  let  your  readers  know  that  I’ve 
also  posted  numerous  articles  on  my 
Web  site  on  the  JAD  topic.  There  are 
pages  that  provide  practitioners  with 
checklists,  tips,  examples,  questions  and 
templates  that  are  useful  for  planning 
and  running  workshops. 


Ellen  G  ottesdiener 
EBG  Consulting  Inc. 
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Weather-Impact  Decision  Aids  Software  to 
Help  Plan  Optimal  Sensor  and  System  Performance 

D  r.  Richard  C.  Shirkey  Melanie  G  ouveia 

A  rmy  R  eseardh  L  aboratory  N orthrop  G  rumman 

Weather  can  play  a  decisive  role  in  military  battles,  in  their  planning,  and  in  their  execution.  Weather-impact  decision  aids 
give  the  commander  an  edge  by  allowing  both  a  determination  of  the  optimum  selection  of  weapon  systems  and  a  comparison 
with  threat  systems  under  current  or  forecast  weather.  This  artide  describes  two  weather-tactical  deasion  aids:  the  Integrated 
W eather  E  ffeds  D  etision  A  id  and  the  T arget  A  cquisition  W eapons  Software. 


Weather  is  ubiquitous;  planning  for  it  is 
an  everyday  occurrence,  yet  it  still 
manages  to  foul  up  our  plans.  Recent  mili¬ 
tary  examples  abound,  such  as  dust  clouds 
that  grounded  sorties  in  Operation  Allied 
Force  in  Kosovo.  To  effectively  execute 
missions,  the  military  commander  must  be 
aware  of  the  weather  and  its  impact  on 
his/  her  equipment,  personnel,  and  opera¬ 
tions.  There  are  a  number  of  weather- 
impact  decision  aids  (WIDAs)  that  deter¬ 
mine  weather  effects  on  mission-selected 
equipment  and  operations.  G  enerally,  these 
WIDAs  may  be  broken  into  two  subsets: 
rule-based  and  physics-based. 

Rule-based  WIDAs,  such  as  the  Army’s 
Integrated  Weather  Effects  Decision  Aid 
(IWEDA)  [1],  are  constructed  using 
observed  weather  impacts  that  have  been 
collected  from  field  manuals,  training  cen¬ 
ters  and  schools,  and  subject  matter  experts. 
IWEDA  provides  information  (in  the  form 
of  stoplight  charts)  concerning  which 
weapon  systems  will  work  best  under  fore¬ 
cast  weather  conditions;  no  information  is 
provided  concerning  target  acquisition 
range. 

Physics-based  tactical  decision  aids 
(TDAs),  such  as  the  Tri-Service  Target 
Acquisition  Weapons  Software  (TAWS)  [2], 
employ  physics  calculations  that  have  their 
basis  in  theory  and/or  measurements. 
T  AW  S  determines  the  probability  of  detect¬ 
ing  a  given  target  at  a  given  range  under 
existing  or  predicted  weather  conditions. 
Thus,  physics-based  systems  produce 
results  in  terms  of  a  performance  metric 
that  take  on  a  continuum  of  values  rather 
than  the  simpler  stoplight  results  from  the 
rule-based  systems. 

The  IWEDA 

I  WE  DA,  a  UNIX  -based  program  written  in 
Java,  is  a  collection  of  rules  with  associated 
critical  values  for  aiding  the  commander  in 
selecting  an  appropriate  platform,  system, 
or  sensor  under  given  or  forecast  weather 
conditions.  It  provides  qualitative  weather 
impacts  for  platforms,  weapon  systems,  and 
operations,  including  soldier  performance. 
Each  system  (Army,  Air  Force,  Navy, 


and  threat)  has  its  list  of  relevant  rules, 
which  include  red-amber-green  (unfavor¬ 
able-marginal-favorable)  critical  value  thresh¬ 
olds  for  one  or  a  combination  of  the  envi¬ 
ronmental  parameters  that  affect  the  sys¬ 
tem.  Results  are  displayed  via  a  matrix  of 
impacts  vs.  time  (see  Figures  1  and  2)  and 


map  overlays  (see  Figure  3,  page  18)  for  the 
region  of  interest.  Environmental  data  for 
the  region  of  interest  is  supplied  primarily 
via  the  Army's  Batdescale  Forecast  Model 
[2],  developed  for  short-range  forecasting. 
The  environmental  impact  rules  and  critical 
values  for  the  various  systems  have  been 


Figure  1: 1  WE  DA  W  eather  E  ffed  M  atrioes 
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Figure 2: IWEDA  Fulllmpads 
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Figure  3:  IWE  DA  Map  Overlay  for  AH -64 
TADSTV/DVO 


validated  through  the  Training  and 
Doctrine  Command’s  organizations,  field 
manuals  and  the  National  Ground  and 
Intelligence  Center. 

IWE  DA  is  currently  being  fielded  as 
part  of  the  Army's  Command,  Control, 
Communications,  Computers  and  Intelli¬ 
gence  (C4I)  tactical  weather  system,  the 
Integrated  Meteorological  System.  As  a  C4I 
tool,  IWE  DA  does  not  dictate  a  course  of 
action,  but  only  informs  the  commander 
that  there  will  be  weather  impacts  on  the 
force  (friendly  or  threat). 

IWE  DA  rules,  which  interact  with  the 
weather  database  to  determine  impacts  on 
the  selected  system(s),  are  determined  from 
system  concepts  and  are  embodied  in  a 
computer  database  that  has  been  tied  to  crit¬ 
ical  values.  The  critical  values  are  defined,  in 
a  meteorological  sense,  as  those  values  of 
weather  factors  that  can  significantly  reduce 
the  effectiveness  of,  or  prevent  execution 
of,  tactical  operations  and/  or  weapon  sys¬ 
tems. 

An  example  of  such  a  rule  would  be 
"usage  of  TOW2  is  not  recommended  for 
visibilities  less  than  three  kilometers."  In 
this  example  rule,  a  visibility  of  three  kilo¬ 
meters  (the  critical  value)  has  been  coupled 
with  a  system  (TOW2)  resulting  in  a  rule. 
We  can  further  define  this  critical  value,  or 
range  of  values,  as  the  point  where  the 
occurrence  of  a  meteorological  element 


causes  a  significant  (moderate  or  severe) 
impact  on  a  military  operation,  system,  sub¬ 
system,  or  personnel. 

In  general,  the  rules  are  determined  by 
operational  usage  (as  embodied  in  the  field 
manuals,  etc.),  whereas  the  critical  values  are 
determined  by  doctrine,  safety,  or  engineer¬ 
ing  factors  (people,  modeling,  or  testing). 
Currently  IWE  DA  stores  information  on 
102  systems,  86  of  which  are  friendly,  16  of 
which  are  threat-rated. 

IWEDA  Operational  Usage 

IWE  DA  is  arranged  in  a  fashion  that  pres¬ 
ents  systems,  subsystems  and  components 
in  a  hierarchal  fashion.  A  group  of  systems 
is  called  a  mission;  a  system  often  contains 
one  or  more  subsystems;  the  subsystems 
often  have  one  or  more  components.  The 
user  has  the  option  to  define  which  systems 
belong  to  a  mission  and  to  delete  optional 
subsystems  and  components  from  a  system 
thereby  allowing  a  determination  of  weath¬ 
er  impacts  from  operations  or  missions  at 
the  highest  level  down  to  systems,  subsys¬ 
tems,  and  components  at  the  lowest  level. 

For  missions,  systems,  subsystems,  and 
components,  the  impacts  over  the  forecast 
period  are  shown  on  weather  effects  matri¬ 
ces  (WE Ms,  see  Figure  1).  The  WEM  is 
color-coded;  for  use  with  non-color  print¬ 
ers,  cells  are  annotated  with  R  (red),  A 
(amber),  or  G  (green).  Red  areas  indicate 
that  operations  are  severely  impacted:  There 
is  either  a  total  or  severe  degradation  or  the 
operational  limits  or  safety  criteria  have 
been  exceeded.  Amber  indicates  that  opera¬ 
tions  are  marginal  and  the  operational  capa¬ 
bility  is  degraded,  or  there  is  a  marginal 
degradation.  Green  indicates  that  there  are 
no  operational  restrictions. 

Based  on  requirements,  users  may  query 
and  view  various  levels  of  information:  text 
impact  statements  or  spatial  distributions  of 
impacts  on  a  map  overlay. 

IWEDA  Example 

In  the  following  example,  a  user-defined 
mission  is  created  by  selecting  three  friend¬ 
ly  and  two  threat  systems.  0  nee  the  mission 
has  been  configured,  the  database  is  queried 
to  determine  the  weather  impacts  on  the 


T  able  1 : 1  mpads  for  the  AH -64  System  for  22/12 

System  AH-64  has  marginal  impact:  High  Pressure  Altitude _ 

Subsystem  30  MM  MACHINE  GUN  has  marginal  impact:  Low  Visibility _ 

Component  THERMAL  SIGHT  has  marginal  impact:  Reduced  Visibility _ 

Component  TV/DIRECT  VIEW  SIGHT  has  marginal  impact:  Reduced  Visibility _ 

Component  TV/DIRECT  VIEW  SIGHT  has  unfavorable  impact:  Fog  and  Low  Visibility 

Component  Laser  R/D  has  marginal  impact:  Reduced  Visibility _ 

Component  Laser  R/D  has  unfavorable  impact:  Low  Visibility _ 

Subsystem  HELLFIRE  has  marginal  impact:  Icing  Aloft _ 

Subsystem  GENERATOR  has  marginal  impact:  High  Altitude _ 

Component  NIGHT  VISION  GOGGLES  has  unfavorable  impact:  Reduced  Illumination 


systems,  their  subsystems,  and  components. 
Results  are  presented  as  a  function  of  time 
and  location. 

To  construct  the  example  mission,  the 
A-10,  AH-64,  personnel,  SA-14,  and  SA-16 
systems  were  selected  from  IWE  D A's  friend¬ 
ly  and  threat  graphical  user  interfaces  (G  UI). 
Once  these  systems  have  been  selected, 
IWEDA  determines  the  weather  impacts 
on  the  mission;  results  are  presented  to  the 
user  in  the  form  of  a  WEM,  as  shown  in 
Figure  1. 

Initially,  the  lower  half  of  the  WEM  is 
blank  with  the  upper  half  showing  the 
weather  impacts  as  a  function  of  system(s) 
and  time.  By  performing  a  right  click  on  any 
of  the  colored  cells,  such  as  the  AH-64  for 
22/ 12  (day/  time),  condensed  impacts  are 
shown  in  a  scrollable  window  in  the  lower 
half  of  the  WEM  (impacts  for  the  config¬ 
ured  AH-64  system  have  been  reproduced 
in  Table  1).  The  WEM  shows  impacts  on 
the  AH-64  system  as  a  function  of  time  and 
general  environmental  conditions,  but  we 
do  not  know  the  full  (detailed)  impact  or 
where  the  impact  is  occurring  within  the 
forecast  area. 

To  determine  the  full  impact  statement 
and  the  location,  a  left  mouse  click  is  per¬ 
formed  on  the  AH-64  cell  for  the  selected 
day  of  the  month  and  time,  i.e.,  22/ 12.  This 
brings  up  the  next  screen  (see  Figure  2)  that 
presents  all  of  the  selected  AH-64  subsys¬ 
tems  and  components  and  their  color- 
coded  impacts. 

As  in  the  WEM  GUI,  initially  only  the 
top  half  of  Figure  2  is  presented  to  the  user. 
To  obtain  further  information,  the  user 
clicks  on  one  of  the  colored  blocks;  in  the 
example  presented,  the  TV/ direct  view 
sight  component  of  the  Target  Acquisition 
Designation  Sight  (TADS)  has  been  inter¬ 
rogated.  This  results  in  a  color-coded  map 
overlay  (Figure  3)  showing  where  the 
TV/  D  is  affected  by  the  weather.  The  full 
impact  statement,  along  with  its  source,  can 
now  be  obtained  by  moving  the  cursor 
(shown  as  a  white  circle)  and  clicking  upon 
a  white  area  on  the  map  (upper  left  of  cen¬ 
ter). 

The  associated  full  impact  statement 
then  appears  in  the  lower  half  of  Figure  2, 
which  in  this  case  is  "Any  occurrence  of  fog 
or  visibility  <1.9  mi  (3100m)  significantly 
reduces  the  target  and  background  contrast 
making  target  acquisition  difficult." 
Contrast  this  with  the  condensed  impact 
statement  of  "Fog  and  Low  Visibility" 
shown  in  the  WEM. 

In  summary,  the  colored  cells  in  the 
WE  M  display  the  worst-case  condition  for  the 
selected  mission,  during  the  selected  time,  for 
the  entire  forecast  region.  If  the  user  wishes  to 
know  why  a  particular  cell  is  red  or  amber, 
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further  information  is  available  in  impact 
statements,  which  explain  why  a  particular 
cell  exists.  Detailed  analysis  for  the  impact¬ 
ed  system  or  sensor  can  be  obtained  from 
the  color-coded  map. 

TheTAWS 

TAWS  [3],  a  GUI-based  program  running 
under  the  Windows  operating  system,  is  a 
Tri- Service  program  that  includes  Air 
Force,  Army,  and  Navy  sensors  and  targets. 
TAWS  supports  systems  in  three  regions  of 
the  spectrum:  visible  (0.4  -  0.9  microns), 
laser  (1.06  microns),  and  infrared  (IR)  (3-5 
microns;  8-12  microns).  It  accepts  current 
or  forecast  weather  data  to  determine  target 
detection  range  for  selected  sensors  and  tar¬ 
gets.  The  commander  uses  this  information 
for  mission-planning  purposes  or  to  ascer¬ 
tain  which  sensors  can  see  the  furthest 
under  the  given  weather  conditions. 

TAWS  performs  both  illumination  and 
performance  prediction  calculations  (PPC). 
The  PPC  can  be  done  for  single  or  multiple 
locations  during  a  mission.  The  illumination 
analysis  involves  the  computation  of  solar 
and  lunar  ephemeris  information  for  a  spec¬ 
ified  location.  A  mission  planner,  for  exam¬ 
ple,  might  be  interested  in  an  illumination 
analysis  to  determine  the  time  of  sunset  for 
a  particular  mission  date  and  location.  For  a 
single  location,  the  PPC  could  be  used  to 
predict  detection  range  for  a  particularly 
important  target  as  a  function  of  time, 
while  a  PPC  for  multiple  locations  along  a 
mission  route  would  be  useful  to  a  mission 
planner  predicting  detection  ranges  for  a 
series  of  key  locations  as  a  function  of  time. 

To  determine  the  acquisition  range  to  a 
given  target  a  number  of  quantities  need  to 
be  known:  the  target-to-background  con¬ 
trast,  the  atmospheric  conditions,  solar  or 
lunar  luminance,  and  sensor  characteristics, 
all  of  which  vary  with  spectral  region.  We 
discuss  each  of  these  in  the  following  sec¬ 
tions  and  provide  an  illustrative  example  at 
the  end. 

Target-to-Background  Contrast 

Contrast  is  defined  as  the  ability  of  an 
observer  to  distinguish  an  object  from  its 
background;  it  degrades  as  the  atmospheric 
path  length  increases.  At  visible  wave¬ 
lengths,  where  radiation  scattering  from 
atmospheric  particulates  is  important,  the 
mathematical  formulation  of  the  contrast  is 
different  than  in  the  infrared  (IR),  where 
emission  is  the  dominant  process.  Since 
TAWS  computes  contrast  in  both  of  these 
spectral  regions,  we  present  the  following 
formulations. 

Visual  Contrast  Model:  The  inherent,  or 
zero  range  (usually  defined  as  the  target’s 


position),  contrast  at  visible  wavelengths, 
C(0),  is  the  difference  between  the  target, 
If- ,  and  background,  I/),  radiances,  divided 
by  the  background  radiance, 

C(0)  =  [lt(0)-lb(0)]/lb(0).  (1) 

We  may  express  the  apparent  contrast  at 
ranger  as 


1+[  lp(r)/lb(0)][  1/T(r)]  ’  (2) 

where  T(r)  is  the  atmospheric  transmission, 
and  Ip  is  radiation  scattered  from  atmos¬ 
pheric  aerosols  and  gases  into  the  line-of- 
sight.  L  is  called  the  path  radiance  and  may 
be  thought  of  as  atmospheric  noise  scat¬ 
tered  into  the  sensor's  field  of  view;  it  is  not 
dependent  upon  the  target. 

In  TAWS  at  visible  wavelengths,  the  tar¬ 
get  and  background  radiances  are  deter¬ 
mined  using  Hering  and  Johnson's  Fast 
Atmospheric  SCATtering  model  (FASCAT) 
[4],  which  calculates  upwelling  and  down- 
welling  radiance  terms  at  specified  heights 
in  the  atmosphere. 

For  designated  sensor  and  target  alti¬ 
tudes,  the  apparent  contrast  is  calculated  for 
slant  paths,  which  may  include  an  optional 
cloud  layer.  Objects  in  sunlight  or  shadow 
may  be  viewed  against  sky,  cloud,  or  terrain 
backgrounds.  The  path  radiance  I„  and  the 
background  radiance  1 5  are  determined  by 
a  multiple  scattering  calculation  using  the 
delta-Eddington  approximation  [5]  in  con¬ 
junction  with  the  atmospheric  model.  The 
contrast  is  subsequently  determined  using 
equation  (2). 

For  visible/  near-IR  scenarios,  the  target 
may  be  on  the  ground  or  elevated.  An  ele¬ 
vated  target  may  be  viewed  with  an  upward 
or  downward  line-of-sight  (LO  S).  Sky  and 
cloud  backgrounds  are  supported  for  the 
upward  LOS;  distant  earth  and  low-lying 
cloud  backgrounds  are  supported  for  the 
downward  LO  S. 

Thermal  Contrast  Model:  The  inherent 
contrast  at  thermal  wavelengths  is  defined 
as  the  target  temperature  minus  the  back¬ 
ground  temperature, 

C(0)  =  [lt(0)-lb(0)]  =  AT,  (3) 

where  AT  is  the  temperature  difference 
between  the  target  and  background.  Note 
that  as  the  temperature  increases,  so  will  the 
inherent  radiance,  1(0).  Thus,  the  contrast  in 
the  IR  is, 

C(r)  =  C(0)  T(r)  =  AT  T(r).  (4) 

In  TAWS,  C(0)  is  determined  indirectly 


by  the  Multi-Service  Electro-optic  Signature 
model  (MuSES)  [6],  which  calculates  the 
equilibrium  background  and  target  temper¬ 
atures  using  antecedent  illumination  and 
weather  data 

MuSES  has  two  primary  components:  a 
thermal  analyzer  module  and  a  signature 
model.  Thermal  analysis  is  the  computation 
of  physical  temperature  and  heat  rates  that 
are  obtained  through  energy  balance  on  a 
node  or  isothermal  element  using  a  finite- 
difference  numerical  solution  of  the  differ¬ 
ential  equations.  The  main  output  of  a  ther¬ 
mal  model  is  physical  temperatures  and  net 
heat  rates  that  compare  to  empirical  meas¬ 
urements  of  contact  sensors. 

The  signature  analysis  is  the  computa¬ 
tion  of  apparent  temperature  or  radiance, 
which  is  composed  of  an  emitted  compo¬ 
nent  that  is  a  function  of  physical  tempera¬ 
ture  and  emissivity  and  a  reflected  compo¬ 
nent  that  is  a  function  of  irradiance  from  its 
surroundings  and  its  reflectivity.  In  other 
words,  the  signature  is  what  a  sensor  views 
and  measures  the  radiance  of  a  target, 
which  is  only  partially  dependent  on  its 
physical  temperature.  Thus,  the  signature 
model  provides  a  link  between  the  output 
of  the  thermal  model  and  the  desired  out¬ 
put  in  signature  analyses. 

The  basic  heat  source  components  con¬ 
sidered  by  MuSES  include  longwave  radia¬ 
tion,  solar  absorption,  engine  heating, 
engine  compartment  air,  exhaust  gas,  track 
and  wheel  heating,  and  convection.  Inter¬ 
reflections  between  diffuse  surfaces  are  also 
taken  into  consideration.  These  various 
temperatures  and  effects  are  used  to  calcu¬ 
late  AT. 

Laser  Contrast  Model:  The  laser  model 
does  not  compute  contrast. 

Atmospheric  Information 

To  determine  the  loss  of  energy  as  radiation 
passes  through  the  atmosphere  requires 
knowledge  of  the  atmospheric  constituents 
(gases  and  aerosols)  and  its  state  (pressure, 
temperature,  relative  humidity,  etc.).  This 
loss  of  energy  is  expressed  in  the  form  of 
atmospheric  transmission,  which  ranges  in 
value  from  zero  to  one  and  is  highly 
dependent  upon  the  aerosol  type  present. 
This  loss  of  energy  can  be  represented  by 
Beer's  law  for  atmospheric  transmission, 

T(r)  =  e"  (ka  +  kp  +  km)  r,  (5) 

where  ka,  kp,  and  km  are  the  aerosol,  pre¬ 
cipitation,  and  molecular  extinction  coeffi¬ 
cients,  respectively.  The  molecular  extinc¬ 
tion  coefficients  are  determined  in  TAWS 
by  using  a  scaled  down  version  of  the  low 
transmission  atmospheric  propagation  code 
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Aerosol 

Properties 

Rural 

Boundary  layer  background  aerosol  found  in  continental  air  masses. 

Urban 

Rural  aerosol  plus  an  added  component  representing  soot-like 
aerosols  that  include  particles  produced  in  urban  and  industrial 
complexes. 

Maritime 

Characterizes  aerosols  that  include  sea-salt  particles;  the  target  area 
is  more  than  a  few  kilometers  inland. 

Tropospheric 

Characterizes  aerosols  found  in  very  clean  air  masses  and  in  the  free 
atmosphere  above  the  boundary  layer. 

Desert 

Characterizes  aerosols  found  in  the  boundary  layer  of  desert,  arid,  or 
semi-arid  climatic  regions. 

Navy  Maritime 

Describes  aerosols  found  in  the  boundary  layer  of  oceanic 
environments;  includes  wind  speed  dependence. 

Advective  Fog 

Characterizes  wet  aerosols  found  in  dense  fogs,  where  visibility  is 
less  than  1  km. 

Radiative  Fog 

Describes  aerosol  properties  in  less  dense  fogs,  where  visibility  is  1  km 
or  greater. 

Camouflage  Smokes 

Characterizes  white  phosphorus,  fog  oil,  and  hexachloroethane 
smoke. 

Battlefield  Induced 
Contaminants  (BIC) 

A  persistent  pall  of  smoke  and  dust  that  sometimes  covers  areas 
where  intense  combat  has  occurred. 

Table  2:  TA  W  S  A  erosol  M  odds 


LOWTRAN  [7],  The  aerosol  extinction 
coefficients  [8,  9]  are  read  from  pre-calcu- 
lated  internal  tables. 

TAWS  contains  10  aerosol  and  two  pre¬ 
cipitation  models  that  are  used  in  various 
combinations  by  the  IR,  television/ night 
vision  goggles,  and  laser  models  to  deter¬ 
mine  the  appropriate  aerosol  and/  or  pre¬ 
cipitation  extinction  coefficients.  The 
aerosols  describe  the  primary  particulates  of 
the  air  mass  close  to  the  surface  at  the  loca¬ 
tion  of  interest.  The  naturally  occurring 
aerosols  include  rural,  urban,  maritime,  tro¬ 
pospheric,  desert,  advective  fog,  radiative 
fog,  and  Navy  maritime.  There  are  three 
types  of  camouflage  smokes:  white  phos¬ 
phorus,  fog  oil,  and  hexachloroethane.  A 
10th  aerosol,  in  the  form  of  battlefield 
induced  contaminants,  is  available  for  situa¬ 
tions  where  there  is  a  persistent  pall  of 
smoke  and  dust  raised  by  combat. 
Properties  of  the  aerosol  models  are  pre¬ 
sented  in  Table  2.  TAWS  also  contains  rain 
and  snow  precipitation  models. 

TAWS  allows  a  wide  range  of  meteoro¬ 
logical  conditions,  all  of  which  may  be 
selected  by  the  user  and  some  of  which  may 
be  automatically  input  via  the  Air  Force 
Weather  Agency  (AFWA)  or  the  Navy 
Tactical  Environmental  Data  Server 
(TEDS).  These  meteorological  parameters 
include  the  following  (those  values  noted 
with  an  asterisk  may  be  downloaded  from 
AFWA  or  TEDS):  atmospheric  dewpoint 
temperature*;  sea  surface  temperature*; 
wind  velocity/  direction*;  visibility*;  precip¬ 


itation  type/  rate;  surface  aerosol  type;  bat¬ 
tlefield  induced  contaminants;  high-,  mid-, 
and  low-level  clouds*;  and  the  boundary 
layer  height. 

Solar/Lunar  Illumination 

Illumination  analysis  in  TAWS  involves  the 
computation  of  solar  and  lunar  ephemeris 
data  for  a  specified  location  and  a  series  of 
dates  or  times.  Solar/  lunar  ephemeris  input 
information  is  derived  from  user-input  time 
of  day/  time  of  year  and  latitude/  longitude, 
in  conjunction  with  the  Solar-Lunar 
Almanac  Code  [10], 

The  solar/  lunar  ephemeris  information 
is  also  computed  and  used  for  target  acqui¬ 
sition  analysis.  In  this  case,  in  conjunction 
with  variable  cloud  cover,  the  solar/ lunar 
position  is  used  to  calculate  target/ back¬ 
ground  heating  for  the  IR  model  and  inher¬ 
ent  target/  background  radiance  for  the  vis¬ 
ible  model.  The  laser  model  does  not  use 
ephemeris  information. 

Sensor  Information 

Sensors  are  user-selected  once  the  spectral 
region  has  been  chosen.  The  relevant  sensor 
curve  is  automatically  retrieved  from  the 
sensor  database. 

Within  TAWS,  target  detection  range 
for  Silicon  Television  (TV),  night  vision 
goggles  (NVG),  and  IR  sensors  is  deter¬ 
mined  by  using  the  Acquire  sensor  per¬ 
formance  model  [11],  Acquire  predicts  tar¬ 
get  detection  and  discrimination  range  per¬ 
formance  for  systems  that  image  in  the  vis¬ 


ible  and  infrared  spectral  bands.  Ranges  and 
probabilities  predicted  by  the  model  repre¬ 
sent  the  expected  performance  of  an 
ensemble  of  trained  military  observers  with 
respect  to  an  average  target  having  a  speci¬ 
fied  signature  and  size.  TAWS  currently 
only  supports  detection  ranges;  other  acqui¬ 
sition  ranges  are  scheduled  to  be  added  in 
the  near  term. 

TAWS  supports  two  different  classes  of 
systems  that  employ  laser  designators  oper¬ 
ating  at  1 .06  microns:  laser  ranging  and  laser 
lock-on  systems.  Each  of  these  has  designa¬ 
tor  and  receiver  components.  The  airborne 
laser  ranging  systems  measure  the  distance 
from  the  ranger  system  to  the  target  by 
measuring  the  travel  time  of  the  laser  pulse 
from  the  designator  to  the  target  and  from 
the  target  to  the  receiver.  The  designator 
and  receiver  are  physically  collocated  in  the 
same  hardware  package  for  all  ranging  sys¬ 
tems.  For  the  laser  lock-on  weapons,  the 
designator  illuminates  the  target  and  the 
receiver  receives  the  reflected  beam.  TAWS 
predicts  the  maximum  effective  range  for 
either  the  designator  or  lock-on  receiver. 

Example 

We  present  here  a  winter  scenario  using  a  T- 
80  Soviet  main  battle  tank  in  exercised  and 
off  modes,  against  a  snow  background  at 
IR  wavelengths.  The  sensor  and  tank  were 
aligned  such  that  the  sensor  always  had  a 
frontal  view  of  the  tank;  the  sensor  height 
was  10  feet.  The  date  and  location  were 
fixed  at  21  December,  latitude  37°  32'  N, 
longitude  127°  00’  E  (Seoul,  S.  Korea), 
respectively.  The  weather  conditions  were 
overcast  and  snowing  with  visibilities  of 
three  miles  (light  snow)  and  one  mile  (heavy 
snow)  with  a  light  breeze  (~3m/  s)  from  the 
west.  The  relative  humidity  and  tempera¬ 
ture,  taken  from  a  climatological  database 
[12],  as  a  function  of  local  time  are  present¬ 
ed  in  Table  3. 

The  results  of  the  model  run  are  shown 
in  Figure  4.  The  two  vertical  lines,  deter¬ 
mined  using  the  illumination  analysis  capa¬ 
bility  of  TAWS,  indicate  the  sunrise  and 
sunset  times.  As  expected,  the  detection 
range  is  considerably  larger  when  the  visi¬ 
bility  is  higher;  for  given  weather  conditions 
the  exercised  tank  is  easier  to  detect  relative 
to  the  tank  in  the  off  state. 

Thermal  crossover,  defined  as  the  time 
during  the  day  when  the  thermal  contrast  is 
at  a  minimum  and  the  polarity  of  the  con¬ 
trast  reverses,  generally  occurs  at  mid- 
morning  and  late  afternoon.  For  example, 
in  early  morning  the  background  tempera¬ 
ture  may  be  greater  than  the  target  temper¬ 
ature.  After  thermal  crossover,  the  target 
temperature  may  be  greater  than  the  back¬ 
ground  temperature.  In  the  example,  ther- 


Table  3:  Input  R dative H  umidity  (RH )  (% )  and  T emperature  (°C)  as  a  Function  of  Time  (HRS) 


Time 

1800 

2100 

0000 

0300 

0600 

0900 

1200 

1500 

1800 

2100 

0000 

Temp 

1 

-3 

-3 

-5 

-5 

0 

0 

1 

1 

-3 

-3 

RH 

69 

74 

74 

86 

86 

80 

80 

69 

69 

74 

74 
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mal  crossover  occurs  at  approximately  0900 
and  1700,  accounting  for  the  low  detection 
range  at  those  times.  The  commander/  user 
can  now  optimize  assets  by  choosing  a  time 
when  detection  range  is  maximized  and  by 
avoiding  those  times  such  as  when  thermal 
crossover  occurs,  when  detection  ranges  are 
at  a  minimum. 

Using  this  information  in  conjunction 
with  weather  forecast  information  (as 
opposed  to  static  information  used  in  this 
example)  provides  additional  relevant  infor¬ 
mation.  For  example,  let  us  examine  the 
"tank  on"  curves  in  Figure  4.  If  the  weath¬ 
er  conditions  were  predicted  to  change 
from  heavy  to  light  snow  at  1200  local,  the 
detection  range  would  increase  from 
approximately  one  and  one-half  kilometers 
to  approximately  four  and  one-half  kilome¬ 
ters,  providing  the  commander  with  an 
opportunity  for  increased  detection.  Such 
scenarios  may  also  be  used  for 
friendly/ threat  comparisons  to  determine 
the  delta  in  range  due  to  differing  systems. 

Conclusions 

I  WE  DA  provides  the  commander  with  an 
easy-to-use  and  interpret  tactical  application 
that  allows  for  near  real-time  evaluation  of 
sensor  employment  options.  Automating 
the  environmental  parameter  retrieval  by 
using  a  prognostic  data  set  further  enhances 
the  application  and  allows  for  realistic  plan¬ 
ning  based  on  evolving  weather. 

TAWS  aids  the  warfighter  in  determin¬ 
ing  what  sensor/  weapon  system  will  work 
best  against  a  user- selected  target  under 
adverse  weather  conditions.  TAWS  accom¬ 
plishes  this  by  using  accepted  sensor  per¬ 
formance  and  aerosol  models  coupled  with 
proven  technigues  for  determining  atmos¬ 
pheric  transmission  and  contrast.  In  addi¬ 
tion  to  determination  of  acquisition  ranges, 
TAWS  may  be  used  for  mission  planning 
and  for  determination  of  deltas  between 
friendly  and  threat  systems. 

Taken  together,  these  TDAs  provide  the 
commander  a  significant  advantage  for  sys¬ 
tem  selection  under  adverse  weather  condi- 
tions.4 
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Get  Back  to  the  A-B-Cs  of  Software  Management 
with  the  2003  STSC  Seminar  Series 


For  the  third  year,  the  Air  Force’s  Software  Technology  Support  Center  (STSC)  is  offering  a  series  of  informative  software- 
related  seminars  in  a  workshop  environment.  This  year’s  series  will  focus  on  some  of  the  fundamentals  of  software  manage¬ 
ment  in  acquisition  and  development  programs  -  a  Back  to  Basics. 

The  2003  STSC  seminar  series  will  include  these  topics: 


January  14-16 
February  18-20 
March  11-13 
April  22-24 
May  13-15 
June  17-19 
July  15-17 
August  19-21 

September  16-18 
October  14-16 
November  18-19 


Life-Cycle  Software  Project  Management 
Life-Cycle  Software  Project  Management 
The  Requirement  for  Good  Requirements 
The  Requirement  for  Good  Requirements 
Software  Schedule  and  Cost  Estimation 
Introduction  to  CMMI 
Introduction  to  CMMI 
The  Risks  of  Not  Being  Risk  Conscious: 

Software  Risk  Management  Basics 
Software  Quality  Assurance 
Why  Is  Buying  Software  So  Difficult? 

Bringing  It  All  Together  for  the  Software  Manager 
(Software  Best  Practices:  An  Executive’s  Perspective) 


Hill  AFB  Vicinity 
Hanscom  AFB  Vicinity 
Hill  AFB  Vicinity 
Hanscom  AFB  Vicinity 
Hill  AFB  Vicinity 
Hanscom  AFB  Vicinity 
Hill  AFB  Vicinity 

Hill  AFB  Vicinity 
Hill  AFB  Vicinity 
Hill  AFB  Vicinity 
Hill  AFB  Vicinity 


Senior  managers,  project  managers,  project  leads,  and  projects  team  members  would  all  benefit  from  these  seminars  that  are 
FREE  to  U.S.  government  employees;  however,  seating  is  limited.  So  act  quickly. 


Seminar  Highlights 


"W  e  will  be  able 
to  put  some  type 
of  standardization 
and  consistency  in 
place." 


Life-Cycle  Software  Project  Management 

You  hear  it  all  the  time:  another  software  development  effort  is 
over  cost  and  the  due  date  long  since  past.  Unfortunately,  this 
has  become  the  norm  rather  than  the  exception.  But  why?  Is  it 
because  we  don’t  know  how  to  manage  software  projects  prop¬ 
erly?  Or  is  it  because  we  don’t  properly  implement  what  we 
know? 


Good  Project  Management  is  the  key  to  a  successful  project. 
Project  Management  for  software  projects  begins  when  a  sys¬ 
tem  is  initially  being  considered  and  continues  until  the  last  oper¬ 
ating  system  is  shut  down.  During  this  life  cycle,  several  areas 
must  be  addressed. 


The  purpose  of  the  Life-Cycle  Software  Project  Management 
seminar  is  to  provide  project  management  instruction  to  those 
who  don’t  know  how  to  manage  software  projects,  and  to  provide 
encouragement  to  implement  proper  software  project  manage¬ 
ment  techniques  to  those  who  do  know  how  to  manage  software 
projects.  This  seminar  addresses  project  initiation,  the  many 


aspects  of  project  planning,  project  monitoring  and  control 
through  project  closeout  and  lessons  learned. 

The  Requirement  for  Good  Requirements 

It  is  a  widely  accepted  premise  that  requirements  are  the  foun¬ 
dation  upon  which  entire  systems  are  developed.  It  is  also  wide¬ 
ly  accepted  that  the  various  requirements  activities  are  often  not 
accomplished  in  an  attempt  to  get  systems  completed  faster. 
This  often  results  in  hours  of  rework,  correction,  and  ultimately 
having  to  settle  for  a  system  that  lacks  the  required  functionality. 

The  seminar,  The  Requirement  For  Good  Requirements ,  covers 
the  fundamentals  of  requirements  engineering,  analysis,  elicita¬ 
tion,  documentation,  and  verification  and  validation.  This  seminar 
will  focus  on  getting  requirements  right  the  first  time.  The  semi¬ 
nar  will  include  training  in  theory  and  applicability  of  all  require¬ 
ments  activities.  It  will  also  include  planned  exercises  to  help  par¬ 
ticipants  solidify  the  concepts  taught.  Additional  reading  materi¬ 
als  will  be  provided  to  highlight  key  topics  that  correspond  to 
seminar  materials. 


For  additional  information  about  these  seminars,  visit  our  Web  site  at  www.stsc.hill.af.mil. 

SPACE  IS  LIMITED.  To  reserve  your  place  at  any  of  these  seminars, 
contact  Debra  Ascuena  at  801-775-5778  (DSN  775-5778)  or  debra.ascuena@hill.af.mil. 
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Software  Schedule  and  Cost  Estimation 

One  of  the  most  dominant  and  serious  complaints  arising  from 
the  “software  crisis”  is  the  inability  to  estimate  with  acceptable 
accuracy  the  cost,  resources,  and  schedule  required  for  software 
development.  Traditional  intuitive  estimation  methods  have  con¬ 
sistently  produced  optimistic  results  that  contribute  to  the  too 
familiar  cost  overrun  and  schedule  slippage. 

The  rapidly  increasing  cost  of  software  has  led  customers  for 
these  products  to  become  less  willing  to  tolerate  the  uncertainty 
and  losses  associated  with  inaccurate  cost  and  schedule  esti¬ 
mates  unless  the  developer  is  willing  to  accept  a  significant  por¬ 
tion  of  that  risk.  This  customer  pressure  emphasizes  the  need  to 
use  an  estimation  method  that  can  be  applied  early  in  the  soft¬ 
ware  development  where  trade-off  studies  and  investment  deci¬ 
sions  are  made.  The  estimation  method  must  be  able  to  consid¬ 
er  the  characteristics  of  the  development  organization  and  the 
environmental  effects  imposed  by  the  development  task,  as  well 
as  the  application  size  and  complexity,  in  order  to  support  rea¬ 
sonable  estimates. 

The  seminar,  Software  Schedule  and  Cost  Estimation,  address¬ 
es  the  fundamental  concepts  of  estimating  and  controlling  soft¬ 
ware  developments,  schedule,  and  costs.  Means  of  early  recog¬ 
nition  of  potential  problems  will  be  discussed.  Exposure  will  be 
given  to  various  estimation  methods  and  approaches.  Data  col¬ 
lection  and  validation  techniques  to  improve  the  estimation 
process  will  be  presented  and  experience  estimating  the  size 
and  complexity  of  a  software  development  task  will  be  provided. 

Introduction  to  CMMI 

This  seminar  is  the  Introduction  to  CMMI  course  that  was  devel¬ 
oped  by  the  Software  Engineering  Institute  (SEI).  This  course  is 
centered  on  the  Capability  Maturity  Model  (CMM®)  Integration^ 
(a  service  mark  of  SEI).  The  model  is  intended  to  provide  guid¬ 
ance  for  improving  your  organization’s  processes  and  your  abili¬ 
ty  to  manage  the  development,  acquisition,  and  maintenance  of 
products  and  services.  CMMI  places  proven  practices  into  a 
structure  that  helps  your  organization  assess  its  organizational 
maturity  and  process  area  capability,  establish  priorities  for 
improvement,  and  guide  the  implementation  of  these  improve¬ 
ments. 

This  seminar  will  provide  attendees  with  the  following: 

•  CMMI  overview. 

•  Engineering  process  maturity:  CMMI  principles. 

•  Capability  levels  and  process  areas  of  the  CMMI  Model 
Continuous  Representation. 

•  Linking  the  process  areas  together. 

•  Interpreting  CMMI. 

•  Application  of  CMMI. 

The  Risks  of  Not  Being  Risk  Conscious: 

Software  Risk  Management  Basics 

A  recent  insurance  industry  television  advertisement  portrays 
individuals  parachuting,  bungee  jumping,  and  participating  in 
other  seemingly  dangerous  activities.  The  participants  are  then 
asked  to  drive  on  U.S.  highways  without  insurance  coverage. 
When  presented  with  this  situation,  the  individuals  flee  in  fear. 
The  risk  associated  with  driving  without  insurance  is  considered 
too  great. 

We  consistently  see  software  programs/projects  that  blindly  ven¬ 
ture  forward  with  little  or  no  consideration  for  the  risks  that  may 
be  encountered  along  the  way.  Some  of  these  projects  face  risks 
similar  in  magnitude  to  that  portrayed  in  the  insurance  example. 
This  lack  of  proper  software  risk  management  places  numerous 
software  projects  at  risk  of  failure. 


The  purpose  of  The  Risks  of  Not  Being  Risk  Conscious: 
Software  Risk  Management  Basics  seminar  is  to  provide  risk 
management  instruction  to  those  responsible  for  software  proj¬ 
ects.  This  seminar  will  educate  attendees  of  the  value  and 
rationale  for  performing  risk  management.  Participants  will  gain 
both  theoretical  and  practical  knowledge  to  assist  them  in  prop¬ 
erly  identifying,  analyzing,  and  mitigating  program/project  risks 

Software  Quality  Assurance 

We  hear  a  lot  today  about  quality  with  regard  to  products  and 
services.  Organizations  undertake  quality  initiatives  with  the 
intent  to  improve  customer  satisfaction  and  thus  increase  rev¬ 
enues.  It  has  been  said  that  quality  is  that  illusive  characteristic 
that  is  hard  to  define,  impossible  to  measure,  yet  easy  to  recog¬ 
nize. 

The  IEEE  Handbook  of  Software  Quality  Assurance  defines  soft¬ 
ware  quality  assurance  as  the  set  of  systematic  activities  provid¬ 
ing  evidence  of  the  ability  of  the  software  process  to  produce  a 
software  product  that  is  fit  for  use.  A  more  fitting  definition  may 
be  simply  keeping  the  customer  happy. 

The  seminar,  Software  Quality  Assurance,  addresses  the  funda¬ 
mental  concepts  of  quality  assurance  relative  to  software  proj¬ 
ects.  This  seminar  defines  software  quality  assurance  and 
explores  methods  and  means  of  assuring  quality  in  the  software 
development  and  acquisition  processes. 

Why  Is  Buying  Software  So  Difficult? 

We  buy  things  every  day:  gasoline,  newspapers,  shoes,  and 
even  something  as  common  as  canned  beans.  Acquiring  prod¬ 
ucts  and  services  from  others  is  a  routine  part  of  our  daily  lives. 
So  why  is  buying  software  so  much  more  difficult? 

The  seminar,  Why  Is  Buying  Software  So  Difficult?,  addresses 
the  fundamentals  of  software  acquisition.  During  this  seminar, 
we  will  point  out  the  major  differences  between  purchasing  com¬ 
mon,  everyday  items,  and  purchasing  made-to-order  software. 
We  will  discuss  common  pitfalls  of  software  acquisition  and 
actions  that  should  be  taken  to  avoid  them.  We  will  compare  and 
contrast  software  acquisition  with  hardware  acquisition. 
Additionally,  we  will  discuss  how  acquisition  reform  has  benefit¬ 
ed  (as  well  as  in  some  cases  hindered)  the  software  acquisition 
process.  Particular  attention  will  be  paid  to  recent  changes  in  the 
Department  of  Defense  5000  series  of  regulations  as  they  apply 
to  software  acquisition. 

Bringing  It  All  Together  for  the  Software  Manager 

(Software  Best  Practices:  An  Executive’s  Perspective) 

Numerous  studies  have  been  conducted  documenting  the  value 
to  organizations  of  embracing  best  practices.  Without  exception, 
these  studies  highlight  the  critical  nature  of  executive  or  man¬ 
agement  support  to  the  success  of  any  software  development 
effort. 

This  seminar  was  developed  to  educate  executive  level  person¬ 
nel  as  to  their  role  in  the  successful  execution  of  software  engi¬ 
neering  activities  using  industry  best  practices.  Executives  will  be 
educated  in  best  practices  from  a  systems-thinking  perspective, 
examining  each  life-cycle  activity,  critical  success  factors  and 
measurements,  the  role  of  senior  management,  what  to  look  for, 
and  what  to  ask  for  to  ensure  the  success  of  the  organization  and 
the  program.  Emphasis  will  be  placed  in  key  areas  where  man¬ 
agement  leadership,  direction,  and  support  are  essential  to  suc¬ 
cess.  An  opportunity  to  collaborate  with  other  executives  facing 
the  challenges  associated  with  systems  engineering  will  be  pro¬ 
vided.  Additional  reading  materials  will  also  be  provided  to  high¬ 
light  key  topics  that  correspond  to  industry  best  practices. 


"Excellent  class  - 
0  ne  of  the  best 
government- 
sponsored  classes 
I  have  taken." 


"0  verall 
outstanding!." 


"Very  good 
course  -  more 
professional  than 
any  I've  attended 
in  the  past  few 
years." 


Computer  Resources 
Support  Improvement 
Program 


Software  Technology 
Support  Center 


These  seminars  are  being  offered  by  the  Air  Force’s  Software  Technology  Support  Center  (STSC) 
and  are  being  sponsored  by  the  Air  Force’s  Computer  Resources  Support  Improvement  Program  (CRSIP). 

For  information  about  these  organizations  and  their  services,  please  visit  the  STSC  Web  site  at  www.stsc.hill.af.mil. 
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The  Privilege  and  Responsibility  of  Software  Development 

Grady  Booch 
Rational  Software  Corporation 

A  s  professionals,  it  is  a  tremendous  privilege  to  be  part  of  an  industry  that  delivers  software  that  makes  a  fundamental  dif¬ 
ference  to  our  organizations,  our  country,  and  our  civilization.  A  t  the  same  time,  however,  we  must  realize  that  creating  qual¬ 
ity  software  that  matters  is  intrinsically  hard.  A  s  such,  as  professionals,  we  have  a  deep  responsibility  to  do  our  work  with 
purpose,  courage,  and  a  sense  of  moral  purpose. 


No  one  really  wants  software.  End  users 
typically  hate  software  for  many  rea¬ 
sons.  It  is  that  thing  that  gets  in  the  way  of 
their  work  (by  driving  unnatural  work 
processes).  It  wastes  time  (when  their 
machines  go  down),  distracts  them  (by 
offering  up  a  deluge  of  useless  or  mislead¬ 
ing  information),  and  generally  annoys 
them  (when  the  bones  of  the  underlying 
implementation  show  through).  Users  sim¬ 
ply  want  to  accomplish  their  mission,  and 
insofar  as  any  underlying  software  makes  its 
presence  known,  it  is  counter  to  getting  the 
job  done. 

Program  managers  often  hate  software 
as  well.  It  is  that  thing  that  eats  up  budgets 
with  an  insatiable  appetite  for  growth.  It  is 
terribly  slippery  to  get  ones  hands  around, 
and  even  if  you  do,  it  has  a  tendency  to  slip 
out  of  your  control  at  a  moment’s  notice 
leaving  an  ugly,  smelly  mess  on  the  floor. 

Bad  software  -  and  there  is  far  too 
much  of  it  in  the  world  -  not  only  wastes 
time  and  budgets,  distracts,  and  annoys,  it 
can  also  put  lives,  businesses,  and  whole 
economies  at  risk  [1],  Even  at  its  best,  a 
software-intensive  system  can  amplify 
human  intelligence,  but  it  cannot  replace 
human  judgment;  a  software-intensive  sys¬ 
tem  can  fuse,  coordinate,  classify,  and  ana¬ 
lyze  information,  but  it  cannot  create 
knowledge. 

Still,  we  bring  software  into  our  lives 
and  into  our  systems  for  some  very  basic 
reasons.  There  are  some  things  that  we  can 
do  in  software  that  we  cannot  do  otherwise: 
•  Control  an  aerodynamically  unstable 
aircraft. 

•  Fuse  and  analyze  information  from  a 
multitude  of  sensors  so  as  to  form  a 
unique  view  of  the  world. 

•  Create  virtual  worlds  wherein  experi¬ 
ments  that  would  otherwise  be  too  dan¬ 
gerous  to  conduct  can  be  carried  out. 

•  Search  through  terabytes  of  informa¬ 
tion  in  the  beat  of  a  heart. 
Furthermore,  software  offers  greater 
flexibility  than  can  be  offered  in  hardware, 
which  is  why  the  mix  of  software  to  hard¬ 
ware  within  many  systems  is  growing  in 


favor  of  software.  Finally,  for  the  most 
part,  investment  in  software  has  an  undeni¬ 
able  economic  return:  Across  the  spectrum, 
from  embedded  systems  to  command  and 
control  systems  to  enterprise  information 
systems,  the  presence  of  software  adds 
essential  value,  far  more  than  the  invest¬ 
ment  necessary  to  create  that  software. 

As  I  look  back  over  the  history  of  soft¬ 
ware  development,  it  strikes  me  that  ours  is 
an  industry  that  has  largely  grown  out  of 
demand  from  users  who  want  more  from 
their  systems  for  less.  All  of  our  systems  are 
constrained  by  the  laws  of  physics  and  by  a 

"...  a  software-intensive 
system  can  amplify 
human  intelligence,  but  it 
cannot  replace  human 
judgment ..." 

few  laws  of  software  [1].  But  for  the  most 
part,  it  is  our  ability  as  an  industry  to  devel¬ 
op  better  software  faster,  software  that 
meets  the  needs  of  its  end  users,  that  is  the 
primary  constraint  upon  meeting  our  vision 
for  what  software  can  do  in  the  world. 
Insofar  as  a  given  software  development 
team  can  execute  well,  they  enable  the  mis¬ 
sion  for  which  they  labor;  insofar  as  they 
execute  inefficiently  or  not  at  all,  they  fail 
the  organization  that  commissioned  them. 

In  that  sense,  software  development  is  - 
or  certainly  should  be  -  considered  an 
engineering  discipline.  From  the  perspec¬ 
tive  of  a  software-intensive  project,  there 
exists  the  competing  forces  of  cost,  sched¬ 
ule,  functionality,  compatibility,  perform¬ 
ance,  capacity,  scalability,  reliability,  avail¬ 
ability,  security,  fault  tolerance,  and 
resilience,  all  in  the  presence  of  technology 
and  business  chum.  Balancing  these  forces 
is  very  much  an  engineering  activity.  There 
is  no  such  thing  as  a  perfect  design  or  a  perfect 
system;  indeed,  the  very  presence  of  any 
new  system  changes  the  way  its  stakehold¬ 


ers  view  the  world  and  thus  alters  their 
vision  for  what  that  new  system  should 
have  done  in  the  first  place. 

We  as  developers  are  the  ones  who  do 
the  heavy  lifting,  creating,  and  rearranging 
the  components  that  make  up  our  software 
worlds  to  form  systems  that  balance  these 
forces. 

As  developers,  we  have  all  had  our  share 
of  bad  days:  days  that  our  operating  sys¬ 
tems,  networks,  workstations,  and  co-work- 
ers  conspire  against  us  to  suck  all  produc¬ 
tivity  out  of  the  air;  days  that  our  bosses  or 
their  bosses  or  our  customers  hammer  us 
for  errors  done  or  for  functions  left 
undone;  or  days  that  turn  into  nights  and 
back  into  days  again  as  we  chase  some  elu¬ 
sive  gnome  from  our  system. 

These  are  the  days  of  living  as  a  net- 
slave  [2],  a  microserf  [3],  After  abiding  such 
days  during  which  we  labor  to  build  arti¬ 
facts  that  live  in  the  realm  of  nanoseconds, 
sometimes  we  long  for  a  life  with  "no  unit 
of  time  shorter  than  a  season"  [4], 

Still,  most  of  us  come  to  the  profession 
of  software  development  deliberately,  typi¬ 
cally  because  we  like  to  create  things  from 
pure  thought,  things  that  give  life  to  our 
machines  and  that  matter  to  our  organiza¬ 
tions,  perhaps  even  to  the  world.  For  oth¬ 
ers,  software  creeps  up  behind  us  and  grabs 
us  by  the  neck;  although  we  may  secure  an 
uneasy  truce  with  it  even  though  we  may 
not  be  code  warriors,  we  still  require  some 
degree  of  development  skills  so  that  we  can 
wrestle  that  software  to  the  ground  and 
direct  it  to  carry  out  our  will.  Either  way,  as 
an  intentional  or  as  an  accidental  developer, 
we  build  things  that  the  rest  of  the  world 
needs  and  uses  and  yet  are  often  invisible  to 
them. 

For  this  reason,  it  is  both  a  privilege  as 
well  as  a  deep  responsibility  to  be  a  soft¬ 
ware  developer. 

It  is  a  privilege  because  -  in  spite  of 
some  inevitable  dark  days  -  we  collectively 
are  given  the  opportunity  to  create  things 
that  matter:  to  individuals,  to  teams,  to 
organizations,  to  countries,  to  our  civiliza¬ 
tion.  We  have  the  honor  of  delivering  the 
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stuff  of  pure  intellectual  effort  that  can 
protect,  defend,  heal,  serve,  entertain,  con¬ 
nect,  and  liberate,  freeing  the  human  spirit 
to  pursue  those  activities  that  are  purely 
and  uniquely  human. 

Paul  Levy,  Rational’s  chairman,  once 
noted  the  following: 

Ultimately,  building  software  [is]  the 
world's  most  important  industry. 
Software  today  allows  a  brother  in 
San  Jose  to  call  a  sister  in  St. 
Petersburg.  Software  today  speeds 
the  process  of  drug  discovery, 
potentially  curing  Alzheimer's. 
Software  today  drives  the  imaging 
systems  that  allow  the  early  detec¬ 
tion  of  breast  cancer  and  other  mal¬ 
adies.  Software  controls  the  passive 
restraint  systems  and  anti-lock 
breaking  systems  that  save  children’s 
lives  in  automobiles  every  day. 
Software  powers  our  communica¬ 
tions  and  transportation  technolo¬ 
gies.  Software  allows  us  to  peer  deep 
within  ourselves  and  study  the 
human  genome.  Software  allows  us 
to  explore  and  understand  our  uni¬ 
verse.  And,  make  no  mistake  about 
it,  we  are  just  getting  started.  [5] 

Simultaneously,  we  have  a  deep  respon¬ 
sibility.  Because  individuals  and  organiza¬ 
tions  depend  on  the  artifacts  we  create,  we 
have  an  obligation  to  deliver  quality  systems 
using  scarce  human  and  computing 
resources  intentionally  and  wisely.  This  is 
why  we  hurt  when  our  projects  fail,  not 
only  because  each  failure  represents  our 
inability  to  deliver  real  value,  but  also 
because  life  is  too  short  to  spend  precious 
time  on  constructing  bad  software  that  no 
one  wants,  needs,  or  will  ever  use. 

As  professionals,  we  also  have  a  moral 
responsibility:  D  o  we  choose  to  labor  on  a 
system  that  we  know  will  fail  or  that  might 
steal  from  another  person  their  time,  their 
liberty,  or  their  life?  Q  uestions  like  this  have 
no  technical  answers,  but  rather  are  ones 
that  must  be  consciously  weighed  by  our 
individual  belief  system  as  we  deploy  tech¬ 
nology  to  the  world. 

At  the  very  least,  the  consequences  of 
our  failure  may  be  as  simple  as  the  delivery 
of  annoying  software,  which  behaves  in 
unexpected  ways  or  is  so  fragile  that  it 
drives  the  user  rather  than  letting  the  user 
drive  it.  Such  software  wastes  our  time  and 
gets  in  the  way  of  accomplishing  real  work. 
At  the  other  extreme,  the  consequences 
may  be  life  threatening:  The  software  fails, 
and  people  die. 

Across  this  entire  spectrum  of  bad  soft¬ 
ware,  it  is  partly  a  failure  of  the  team  in  the 


sense  that  the  organization  failed  to  deliver  a 
useful  system  that  worked.  However,  it  is 
ultimately  a  failure  of  the  individual: 
D  enying  all  responsibility  by  hiding  inside 
an  organization  is  no  excuse  for  this  kind  of 
failure. 

Personal  responsibility  can  manifest 
itself  in  a  variety  of  ways:  arguing  against 
unrealistic  schedules,  working  out  of  the 
box  where  it  might  yield  a  solution  that 
sidesteps  the  current  barriers  to  progress, 
expecting  quality,  and  demanding  the  best 
from  your  colleagues.  To  do  otherwise  per¬ 
mits  an  environment  in  which  a  succession 
of  lies  is  permitted  to  flourish,  with  the 
inevitable  delivery  of  bad  software. 

Thus,  software  development  is  ulti¬ 
mately  a  human  activity,  not  only  because  it 
emanates  from  the  human  intellect,  but  also 
because  it  requires  the  cooperative  activity 
of  others  to  make  it  real. 

As  professionals,  we  therefore  con¬ 
stantly  seek  better  ways  to  deliver  quality 
software  that  matters,  because  the  task  is 
too  complex  to  squander  our  time  and  our 
energy.  This  is  why  we  analyze  why  projects 
were  successful  and  similarly  look  at  failed 
projects  to  learn  from  their  mistakes.  We 
then  codify  all  these  lessons  learned  in  the 
best  practices  and  processes  that  constitute 
our  industry's  tribal  memory,  such  as  found 
in  the  Rational  Unified  Process  and  in 
emerging  ideas  from  extreme  Program¬ 
ming.  For  the  same  reason,  we  agree  upon 
common  notations  such  as  the  Unified 
Modeling  Language  that  help  us  communi¬ 
cate  and  reason  about  our  systems. 

Still,  the  demand  for  software  continues 
to  rise  at  a  staggering  rate.  The  ever-grow¬ 
ing  capabilities  of  hardware  combined  with 
increasing  social  awareness  and  economic 
value  of  the  utility  of  computers  create 
tremendous  pressure  to  automate  systems 
of  even  greater  complexity.  Thus,  our  priv¬ 
ilege  to  carry  out  our  skills  continues,  as 
well  as  does  our  responsibilities. 

Indeed,  as  Levy  said,  "We  are  just  get¬ 
ting  started."  Software  is  perhaps  the  most 
splendid  material  to  build  things:  We  create 
software  from  pure  thought  and  shape  it  at 
will  to  form  new  worlds  limited  only  by  our 
imagination.  As  professionals,  we  labor  to 
build  quality  systems  that  are  useful  and 
that  work.  As  software  engineers,  we  face 
the  task  of  creating  complex  systems  with 
elegance  in  the  presence  of  scarce  comput¬ 
ing  and  human  resources.  Inescapably,  eco¬ 
nomic  realities  demand  that  we  build  such 
systems  purposefully  and  efficiently. 
D  eveloping  quality  software  that  matters  is 
fundamentally  hard;  ultimately,  however, 
our  rewards  are  great,  for  what  we  do  as  an 
industry  changes  the  world. 

And  that  is  why  I  am  -  as  we  all  should 


be  -  both  proud  and  humbled  to  be  called 

a  software  developer.^ 
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Note 

1.  See  "ACM  Forum  on  Risks  to  the 
Public  in  Computers  and  Related 
Systems."  Peter  Neumann  moderator. 
<http:/  /  catiess.ncl.ac.uk/  Risks>. 
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Job  Satisfaction  and  Performance  Viewed 
From  aTvuo  Dimensional  Model 


D  avid  B.  Putman 
A  vionic Software D  evdopment  Branch  (U.S.A  ir Force) 

T  raditional  theory  suggests  that  job  performance  is  affected  by  job  satisfaction;  increase  job  satisfaction  and  you  will  increase 
job  performance.  H  owever,  engineering  staffs  within  the  government  are  prime  examples  of  cases  in  which  reality  does  not 
match  the  theory.  W  hi le  these  engineering  staffs  continue  to  remain  highly  competitive  and  turn  out  high  quality  products,  the 
government  struggles  to  get  a  handle  on  the  pay  disparity  between  the  private  and  public  sectors.  I  contend  that  job  perform¬ 
ance  is  much  more  complex  than  the  traditional  theory.  A  fter  getting  no  satisfaction  from  existing  research,  I  am  proposing 
another  way  to  look  at  job  satisfaction  and  job  performance.  I  have  developed  a  model  that  does  not  strongly  contradict  earli¬ 
er  research,  while  at  the  same  time  addresses  some  of  the  challenges  to  the  earlier  work .  H  opefully,  this  model  will  become  an 
additional  tool  that  you  can  use  when  you  are  dealing  with  job  performance  issues. 


While  working  on  my  master’s  degree 
in  business  administration  (MBA)  in 
the  early  1990s,  I  wrote  a  research  paper 
on  job  satisfaction  vs.  job  performance 
based  upon  the  publicized  work  of  others. 
The  prevailing  theory  was/ is  that 
increased  job  satisfaction  results  in 
increased  performance.  Intuitively  this 
theory  makes  sense.  While  countless  hours 
of  research  and  money  have  been  invested 
in  this  theory,  there  still  seems  to  be  a 
problem  with  encouraging  high  perform¬ 
ance. 

From  the  research  I  performed  in  the 
early  '90s,  I  could  not  come  up  with  a  con¬ 
vincing  argument  to  back  this  theory.  I 
concluded  that  the  two  attributes,  job  sat¬ 
isfaction  and  job  performance,  are  too 
closely  linked  to  one  another,  and  that  they 
affect  each  other.  Here  are  cases  in  point: 
If  a  person  is  highly  satisfied  with  his/  her 
job,  this  would  lead  the  person  to  want  to 
do  a  good  job  and  to  perform  well.  0  n  the 
other  side  is  the  person’s  ability  level.  If 
the  person  is  struggling  with  performing 
the  job,  it  may  give  the  appearance  that  the 
person  is  a  poor  performer  even  though 
he/  she  may  be  exhausting  a  great  deal  of 
effort  in  trying  to  perform  the  job.  This 
person’s  frustration  then  in  turn  leads  to 
poor  job  satisfaction. 

Some  researchers  have  expressed  simi¬ 
lar  ideas,  such  as  performance  affects  satisfac¬ 
tion  [1],  while  one  researcher  went  so  far  as 
to  say  that  there  is  no  relation  [2], 
Intuitively  we  feel  that  there  must  be  a 
relationship.  After  all,  it  makes  sense  in  our 
minds,  researchers  continue  their  efforts 
to  explore  the  concept,  and  many  are  hun¬ 
gry  for  the  latest  information  on  the  sub¬ 
ject. 

Since  1994,  the  federal  government  has 
allowed  the  engineering  pay  scale  to  erode. 
In  an  organization  stymied  by  a  great 
bureaucracy  already  burdened  by  financial 
cuts,  it  is  extremely  difficult  to  find  the 
funds  necessary  to  cover  an  increase  in 


engineering  salaries.  Today,  electronic 
engineers  within  the  federal  government 
perceive  that  they  are  making  much  less 
than  their  counterparts  in  the  private 
industry.  It  is  not  surprising  that  recruiting 
is  extremely  difficult  and  that  those  leaving 
to  take  other  jobs  (e.g.  attrition  excluding 
death  and  retirement)  are  greater  than  the 
other  job  series  on  a  military  base,  and 
morale  has  been  better. 

New  Measure  of  Performance 

So  what  kind  of  effects  has  this  had  on  job 
performance?  Thankfully  our  perform¬ 
ance  is  not  as  bad  as  one  would  predict. 
We  continue  to  deliver  high  quality  prod¬ 
ucts  (I  am  unaware  of  any  customer  com¬ 
plaints  of  bad  quality).  This  observation 
stirred  an  interest  in  me  to  go  back  to  the 
books  and  review  the  latest  research  on 
job  performance.  My  results  were  the 
same  as  before:  The  two  attributes,  job  sat¬ 
isfaction  and  performance,  are  too  closely 
linked  to  one  another.  I  was  once  again  left 
with  the  feeling  that  they  affected  each 
other.  Because  of  this  observation,  I  start¬ 
ed  trying  to  find  another  way  to  look  at  job 
performance. 

To  begin,  I  looked  at  job  satisfaction  as 
a  combination  of  three  elements:  task  sat¬ 
isfaction,  employment  satisfaction,  and 
market  satisfaction. 

Task  satisfaction  comes  from  perform¬ 
ing  the  tasks  required  of  the  job. 
Increasing  a  person's  salary  may  make  an 
undesirable  task  more  bearable,  but  it 
doesn’t  necessarily  make  it  more  enjoyable. 

Employment  satisfaction  consists  of 
elements  such  as  personnel  policies,  bene¬ 
fits,  career  opportunities,  work  environ¬ 
ment,  style  of  management,  fit  in  the 
organization,  etc.  Many  of  these  elements 
are  within  the  company's  control;  others 
are  not.  For  example,  there  may  be  very  lit¬ 
tle  that  a  company  can  do  for  an  employ¬ 
ee  who  does  not  get  along  with  his/  her 
peers.  The  employer  can  try  to  assure  that 


all  individuals  are  treated  professionally, 
but  the  company  cannot  make  the  co¬ 
workers  become  close  friends. 

Market  satisfaction  is  comprised  of 
forces  external  to  the  company  that  affect 
the  individual’s  job.  Political  situations  and 
public  laws  can  easily  affect  job  dissatisfac¬ 
tion.  An  individual  may  be  unhappy  with 
having  to  conform  to  an  0  SHA  law  but 
the  company  cannot  waive  the  require¬ 
ment  to  improve  an  individual’s  job  satis¬ 
faction.  In  most  cases,  market  satisfaction 
will  be  consistent  across  the  job  market; 
the  same  external  forces  will  be  present 
even  if  the  employee  changes  employers. 
However  there  are  differences  in  the  exter¬ 
nal  forces  affecting  jobs  within  the  gov¬ 
ernment  and  those  within  the  private  sec¬ 
tor. 

The  diagram  in  Figure  1  illustrates  the 
assumed  correlation  between  job  satisfac¬ 
tion  and  job  performance.  The  theory  is 
that  the  employee’s  performance  is  in 
direct  correlation  to  their  satisfaction; 
improve  their  satisfaction  and  you  will 
improve  their  performance. 

In  looking  for  a  new  way  to  look  at 
performance  vs.  satisfaction,  I  started  with 
a  very  basic  view:  comparing  the  satisfac¬ 
tion  and  performance  of  a  specific  task.  I 
will  refer  to  these  as  task  satisfaction  and 
task  performance.  Task  satisfaction  is 
strongly  influenced  by  a  person's  aptitude; 
it  is  the  satisfaction  received  by  the 
employee  for  performing  that  specific 
task.  T ask  satisfaction  ex  dudes  any  outside  influ¬ 
ences  on  the  individual's  total  job  satisfaction. 

In  developing  this  model,  I  considered 
the  research  of  those  who  have  performed 
a  great  deal  of  work  in  the  field  of  man¬ 
agement,  including  Peter  D  rucker, 
Herzberk,  and  Maslow  (see  Additional 
Reading).  The  test  of  this  model  was  1)  it 
should  not  strongly  contradict  the  work 
previously  performed,  and  2)  it  should 
help  answer  the  challenges  of  the  earlier 
work. 
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Poor  Performance  Excellent  Performance 

Figure  1  -.Traditional  Satisfhctim  vs,  PerformanoeModd 


In  Figure  2, 1  have  broken  the  relation¬ 
ship  of  performance  and  satisfaction  into 
four  quadrants  to  further  explore  and 
explain  the  complexity  of  the  relationship. 
This  figure  helps  to  understand  the  com¬ 
plexity  while  trying  to  keep  the  concept 
manageable.  There  are  varying  degrees  of 
satisfaction  and  performance  so  it  is  diffi¬ 
cult  to  state  exactly  where  one  would  draw 
the  line  between  high  performance  and 
low  performance  and  between  high  satis¬ 
faction  and  low  satisfaction.  Each  person 
is  somewhere  along  those  two  lines.  We 
can  only  try  to  understand  what  will  hap¬ 
pen  as  the  employees  move  along  those 
lines. 

Figure  2  creates  four  quadrants.  Two 
of  the  quadrants  are  the  ones  referenced 
by  traditional  theory: 

•  High  Task  Satisfaction  and  High  Task 
Performance. 

•  Low  Task  Satisfaction  and  Low  Task 
Performance. 

The  other  two  quadrants  are: 

•  High  Task  Satisfaction  and  Low  Task 
Performance. 

•  Low  Task  Satisfaction  and  High  Task 
Performance. 

My  initial  discussion  using  the  two- 
dimensional  model  will  look  at  the  two 
axes  from  a  positive  viewpoint,  i.e.,  the 
person  wants  to  perform  well. 

High  Task  Satisfaction  and  High 
Task  Performance.  This  individual  loves 
his/  her  job.  He/  she  has  the  aptitude,  the 
skill,  and  resources  necessary  to  perform 
the  assigned  task,  and  he/  she  performs 
the  task  quite  well.  A  person  in  this  quad¬ 
rant  may  become  so  caught  up  in  his /  her 
task  that  the  person  does  not  realize  that 
he/  she  has  worked  past  quitting  time. 

Low  Task  Satisfaction  and  Low 
Task  Performance.  The  manager  should 
consider  whether  or  not  something  is 
missing.  D  oes  the  employee  lack  the  apti¬ 
tude,  the  skills,  or  the  resources  necessary 
to  perform  the  task  well?  Being  in  this 
quadrant  does  not  mean  that  the  employ¬ 
ee  is  not  trying!  From  the  employee’s  per¬ 
ception,  the  employee  may  be  expending 
a  great  deal  of  effort  in  trying  to  complete 
the  task.  The  employee  may  feel  that 
he/  she  is  doing  everything  humanly  pos¬ 
sible  and  he/ she  does  not  understand 
why  management  is  unhappy  with  his/  her 
performance.  This  person  may  experience 
very  low  task  satisfaction  because  he/  she 
finds  it  difficult  or  unfavorable  to  per¬ 
form  the  task.  This  person  may  be  a 
clock-watcher,  never  arriving  early  or  stay¬ 
ing  late  without  being  mandated  and  com¬ 
pensated. 

Low  Task  Satisfaction  and  High 
Task  Performance.  Is  a  person  in  this 


quadrant  really  that  rare?  This  person  is 
indicating  that  they  would  rather  be  doing 
another  job,  but  at  the  same  time  their  per¬ 
sonal  values  are  such  that  they  are  giving 
this  task  their  best  effort.  I  suggest  that 
this  is  a  person  that  you  want  to  keep.  It 
may  well  be  worth  your  effort  to  look  at 
developing  a  graceful  transition  plan  that 
would  allow  this  individual  to  move  to 
another  position  while  minimizing  the 
impact  to  your  present  operations. 

High  Task  Satisfaction  and  Low 
Task  Performance.  From  a  positive 
viewpoint,  a  person  in  this  quadrant  loves 
his/  her  work  but  he/  she  is  not  perform¬ 
ing  as  expected.  The  employee  may  find  it 
hard  to  quit  working  on  a  task  knowing 
that  he/  she  can  always  make  it  better  (i.e., 
a  perfectionist  that  never  finishes  his  task). 
Or,  the  person  may  enjoy  what  he/  she  is 
doing  but  lacks  the  aptitude,  skill,  or  other 
resources  necessary  to  do  the  task  quickly. 

The  discussion  so  far  has  been  from  a 
positive  viewpoint.  If  the  person’s  apti¬ 
tude  is  such  that  they  enjoy  the  tasks  and 
they  have  the  skills  to  perform  the  tasks, 


then  they  have  the  potential  of  being  in 
the  high  satisfaction  and  high  perform¬ 
ance  quadrant.  If  the  basic  needs  are  not 
met,  then  increasing  the  person's  salary  is 
not  going  to  improve  performance.  If  a 
person  should  be  in  the  high  task  satisfac¬ 
tion  and  high  task  performance  quadrant 
and  they  are  not  performing  as  expected 
then  the  question  is  one  of  choice,  "Why 
did  the  employee  conscientiously  or 
unconscientiously  chose  to  move  towards 
the  left  (decreased  performance)  in  Figure 
2?"  Factors  influencing  the  person’s  con¬ 
scious  or  unconscious  movements  along 
the  performance  line  include  those  related 
to  employment  satisfaction  and  market 
satisfaction. 

While  working  on  my  MBA,  I  was  for¬ 
tunate  to  have  the  opportunity  to  take  a 
course  on  business  ethics  [3]  in  which  we 
explored  moral  reasoning.  The  four  levels 
of  moral  reasoning  are  as  follows: 

1.  Reasoning  based  upon  "me."  The  kind 
of  reasoning  that  is  seen  in  children 
and  criminals  such  as,  "I  want  it  there¬ 
fore  I'll  take  it.” 


Figure  2 :TwoD  imensional  V  iew  of  Task  Satisfaction  vs.  Task  Performance 
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2.  Reasoning  based  upon  outside  influ¬ 
ence  like  public  law  or  religious  teach¬ 
ings  such  as,  "It’s  against  the  law  to 
speed,  so  I  don’t  speed,"  or  "It’s  a  sin 
to  steal,  so  I  don’t  steal." 

3.  Reasoning  based  upon  your  personal 
value  system  such  as,  "I  believe  that  by 
helping  others  I  help  to  make  the 
world  a  better  place,  therefore  I  volun¬ 
teer  to  help  others." 

4.  Reasoning  based  upon  the  greatest 
good  for  the  greatest  number.  Political 
leaders  are  often  faced  with  basing 
decisions  on  this  type  of  rational. 

The  lowest  level  of  moral  reasoning  is 

level  1;  the  highest  level  is  to  recognize  the 
various  levels  and  understand  what  level  of 
reasoning  you  are  using.  For  example,  a 
person  may  have  to  base  a  decision  using 
the  greatest  good  for  the  greatest  number 
even  though  that  decision  may  contradict 
the  person’s  own  personal  value  system. 
Recognizing  the  different  levels  of  reason¬ 
ing  will  help  the  person  understand  why 
they  are  anguishing  over  a  decision.  Some 
decisions  are  made  conscientiously  where¬ 
as  others  are  made  unconsciously  such  as 
reactions. 

What  I  am  suggesting  is  that  each  per¬ 
son  is  consciously  or  unconsciously  mov¬ 
ing  along  the  line  from  low  performance 
to  high  performance  based  upon  their 
own  personal  value  system  and  their  moral 
reasoning.  This  is  why  two  individuals  with 
similar  skills,  knowledge,  and  capabilities 
appear  to  be  at  different  ends  of  the  per¬ 
formance  spectrum.  Both  employees  may 
feel  as  though  the  company  does  not  value 
them,  but  the  first  employee’s  value  system 
is  based  upon  the  thinking,  "Two  wrongs 
don’t  make  a  right,  and  I'm  still  going  to 
do  my  best.”  Whereas  the  other  employ¬ 
ee's  value  system  may  be  based  upon, 
"You  get  what  you  pay  for.  You  pay  me 
half  of  what  I  feel  that  I  am  worth,  there¬ 
fore  I'll  produce  half  of  what  I’m  capable 
of  producing." 

We  will  never  be  able  to  pinpoint  an 
exact  correlation  between  job  satisfaction 
and  performance  that  will  work  in  every 
situation.  D  oing  a  job  well  may  improve 
job  satisfaction,  being  satisfied  may 
encourage  a  person  to  try  harder,  and  each 
person’s  personal  value  system  will  have  an 
effect  on  how  he/  she  reacts  to  motivators 
and  impediments.  The  best  you  can  do  is 
try  to  understand  that  performance  is  a 
complex  issue,  and  recognize  where  you 
have  control  to  address  issues  affecting  an 
individual's  perform ance> 
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this  holiday  season  and  the  happiest  of  N  e/v  Years 
M  ay  it  bri  ng  peace  to  an  uncatai  n  world. 
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B ackTalk 


Beware  the  Engineer 


I  need  to  begin  this  column  by  saying  that 
everybody  has  a  few  obsessions.  What’s 
mine?  I  am  extremely  punctual.  My  watch 
is  set  weekly  (via  WWV;  the  National 
Institute  of  Standards  and  Technology 
short-wave  radio  station).  In  fact,  a  few  of 
my  friends  might  call  me  obsessive-com¬ 
pulsive  about  time. 

Shortly  after  I  married  my  beautiful 
wife  Marcia,  my  wristwatch  broke.  She 
truly  showed  she  understood  my  needs  by 
buying  me  a  very  nice  and  very  accurate 
replacement  -  it  gained  just  two  seconds  a 
week. 

About  three  years  ago,  the  battery  in 
the  watch  died.  I  went  to  the  jewelry  store 
in  the  mall  to  get  a  new  battery.  A  young 
person  who  couldn't  have  completed  high 
school  opened  my  watch,  replaced  the  bat¬ 
tery,  and  reassembled  it.  Later  that 
evening,  I  noticed  that  the  face  of  the 
watch  (the  round  sheet  with  the  numerals 
on  it)  had  slipped  a  few  degrees,  so  that 
the  numerals  no  longer  lined  up  correctly 
with  the  hands.  I  disregarded  my  wife’s 
advice  to  take  it  back  to  the  jeweler  the 
next  day.  Instead,  I  made  the  following 
three  observations:  1)  I  am  a  well-trained 
engineer,  2)  I  have  a  set  of  miniature  tools, 
and  3)  if  the  young  person  not-out-of- 
high-school  could  do  it,  so  could  I! 

Let's  cut  to  the  end  of  the  story.  The 
watch  manufacturer  eventually  sent  the 
watch  back  to  me  with  a  note  saying  it 
would  be  cheaper  to  just  buy  a  new  one. 
Moral  of  the  story:  Engineers  can't  fix 
everything  they  think  they  can.  (Moral  N  o. 
2:  Never  try  to  fix  anything  your  spouse 
gave  you). 

Unfortunately,  you  now  need  to  ignore 
the  moral  of  this  story  (I  know  I  already 
have)  because  you  are  an  engineer.  Would 
a  heart  surgeon  decide  to  do  brain  sur¬ 
gery?  No  way.  Would  a  licensed  plumber 
offer  to  wire  your  house  for  you?  Probably 
not.  Would  a  person  who  has  built  data¬ 
bases  offer  to  help  design  a  real-time  radar 
system?  Sure!  As  a  matter  of  fact,  as  engi¬ 
neers  we  are  expected  to  be  adaptable. 

Look  at  an  employer's  rationale: 
"N obody  has  ever  done  exactly  what  we’re 
doing,  so  we  are  willing  to  take  people 
who  are  just  plain  ol’  good  engineers."  As 
a  matter  of  fact,  as  engineers  you  are 
expected  to  be  flexible  to  a  degree 
unheard  of  in  other  professions.  Let's  face 
it  -  we  are  EXPECTED  to  think  that 
whatever  it  is,  we  can  do  it! 


I’m  not  saying  this  is  a  good  thing,  but 
in  today's  job  market  (where  there  is  still  a 
severe  shortage  of  trained  and  qualified 
engineers),  we  are  willing  to  take  warm 
bodies  and  not  look  at  their  qualifications 
too  closely.  We're  trained  early  to  be  geeks 
and  to  think  that  we  can  fix  almost  any¬ 
thing  (with  incomplete  or  poor  require¬ 
ments,  poor  management ...  don't  get  me 
started!). 

Last  May,  I  wrote  a  B  ac  kTa  I  k  called 
"Week  of  the  Geek.”  In  it,  I  suggested 
several  indicators  that  you  might  have 
geek-like  tendencies.  I  asked  for  addition¬ 
al  suggestions  and  received  quite  a  few.  It 
made  me  feel  good  to  know  two  things:  1) 
people  do  read  this  column,  and  2)  ...  I 
thought  I  was  a  geek? 

As  promised,  here  are  some  of  the 
better  geek  indicators  I  received.  If  you 
read  any  of  these  indicators  and  think, 
"G  ee,  I  do  that!"  well,  it’s  not  just  me  who 
thinks  you're  a  geek,  too! 

•  For  entertainment,  you  read  a  book  on 
mathematics  or  engineering. 

•  You  have  an  integrated  PDA/ cell 
phone/  mobile  Web  device.  Extra  geek 
points  if  you  wear  it  around  your  neck. 

•  You  own  two  or  more  computers,  but 
only  one  of  them  is  functional  at  any 
given  time  because  you're  working  on 
upgrades  to  all  the  rest.  Extra  points  if 
you  have  enough  parts  left  over  from 
previous  computer  upgrades  to  build  a 
whole  new  computer. 

•  Choosing  to  buy  flowers  for  your  girl¬ 
friend  vs.  upgrading  your  RAM  is  a 
moral  dilemma. 

•  In  college  you  thought  the  phrase 
spring  break  meant  mental  fatigue  fail¬ 
ure  (come  on,  think  about  it). 

•  The  sales  people  at  the  local  computer 
store  can't  answer  your  questions. 

•  You  sit  backwards  on  D  isneyland  tides 
to  see  how  they  do  the  special  effects. 

•  You’ve  tried  to  repair  a  $5  radio. 

•  You  look  forward  to  Christmas  so  you 
can  put  the  kids’  toys  together. 

•  You  think  that  people  yawning  around 
you  are  sleep  deprived. 

•  Your  laptop  computer  costs  more  than 
your  car. 

•  A  real  geek  knows  that  "resistance  is 
futile”  is  what  the  Borg  says  in  Star 
Trek,  but  "resistance  is  useless"  is  what 
the  Vogon  say  in  "The  Hitchhikers 
G  uide  to  the  G  alaxy." 

•  Your  watch  does  not  automatically 


synchronize  itself,  but  you  do  have  a 
bookmark  on  your  browser  pointing 
to  the  atomic  clock. 

•  You  find  yourself  interrupting  com¬ 
puter  store  salesmen  to  correct  some¬ 
thing  they  say. 

•  You've  accidentally  dialed  an  IP 
address. 

•  Y our  friends  use  you  as  tech  support. 

•  You’ve  named  a  computer. 

•  Y ou  have  your  local  computer  store  on 
speed  dial. 

•  You  can't  carry  on  a  conversation 
without  talking  about  computers. 

•  Co-workers  have  to  e-mail  you  about 
the  fire  alarm  to  get  you  out  of  the 
building. 

•  You’ve  found  "stray"  diskettes  when 
doing  laundry. 

•  Y our  computer  has  it’s  own  phone  line 
-  but  your  teenager  doesn’t. 

•  Y ou  check  the  national  weather  service 
Web  page  for  current  weather  condi¬ 
tions  (rather  than  look  out  the  win¬ 
dow). 

•  Y our  pet  has  a  Web  page. 

•  You  get  really  excited  when  Yahoo 
adds  your  link. 

•  You've  tried  to  use  your  Palm  IR  port 
to  re-program  Furbies. 

•  Y ou're  definitely  an  old  or  retired  geek 
if  you  talk  about  the  "good  old  days" 
where  you  could  program  your 
T im ex/  Sinclair  with  64  K ILO  BYTE  S. 
Extra  points  if  you  know  CP/M. 
Double  extra  points  if  you  know 
PICK  OS. 

•  You're  an  old  or  retired  geek  if  you 
own  both  a  pocket  protector  and  a 
slide  rule,  and  you  know  how  to  use 
them  both  without  referring  to  the 
instruction  manuals. 

•  You're  an  old  or  retired  geek  if  you've 
ever  mounted  a  magnetic  tape  reel. 

•  You  have  a  license  plate  with  a  pro¬ 
gramming  language  on  it  (or  are  at 
least,  thinking  "Wow  -  That’s  cool!  I 
wish  I  had  one!"). 

•  Y ou  wanted  to  know  if  my  original  list 
was  posted  to  a  list  server. 

Thanks  to  D  awn  Jaeger,  Lynn  Knight, 

Christopher  Smith,  Robert  Smith,  James 

Meyers,  Chuck  Calhoun,  Claire  Jones,  Ray 

Rangel,  Clark  Duplichie,  Bob  Mathis  and 

Joe  Urda,  among  many  others. 

—  David  A.  Cook,  Geek  in  Residence 
Software  Technology  Support  Center 
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2002  U,S.  Governmen  ts  Top  €■  Duality  Boftwarc  Projects 
The  Deimlr-inl  il  Lta  k  mi  anrl  CftuftAETu,*:  bih  ■:  i  it  Birin  accepting 
nomindkrw  Iw  thfl  HW  LAB.  QwtrnfMrtFi  Top  &  Quifeir  Software 
Project!  ^;hlin^Tg  whirTninov-  d  vjfrnn  kirn*.  m%  h  recognized 
and  best  practices  promoted. 

These  prestigious  awards  are  sponsored  by  the  Office  of  the  Under 
Secretary  of  Defense  for  Acquisition  Resources  and  Analysis,  and  are 
aimed  at  honoring  the  best  of  our  government  software  capabilities  and 
recognizing  excellence  in  software  development. 

The  deadline  for  the  2002  nominations  is  December  13,  2002.  You  can 
review  the  nomination  and  selection  process,  scoring  criteria,  and 
nomination  criteria  by  visiting  our  Web  site.  Then,  using  the  nomination 
form,  submit  your  project  for  consideration  for  this  prominent  award. 

Winners  will  be  presented  with  their  award  at  the  15th  annual  Software 
Technology  Conference  in  Salt  Lake  City  and  will  be  featured  in  the 
July  2003  issue  of  CrossTalk  and  recognized  at  the  Amplifying  Your 
Effectiveness  2003  conference. 

www.stsc.hill.af.mil/crosstalk 
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